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Introduction 



L'approche objet est incontournable dans le cadre du developpement de systemes logiciels 
complexes, capables de suivre les evolutions incessantes des technologies et des besoins 
applicatifs. Cependant, la programmation objet est moins intuitive que la programmation 
fonctionnelle. En effet, il est plus naturel de decomposer les problemes informatiques en 
termes de fonctions qu'en termes d'ensembles d'objets en interaction. De ce fait, l'approche 
objet requiert de modeliser avant de concevoir. La modelisation apporte une grande rigu- 
eur, offre une meilleure comprehension des logiciels, et facilite la comparaison des solutions 
de conception avant leur developpement. Cette demarche se fonde sur des langages de mode- 
lisation, qui permettent de s'affranchir des contraintes des langages d'implementation. 

Le besoin d'une methode de description et de developpement de systemes, prenant en compte 
a la fois les donnees et les traitements, a grandi en meme temps que la taille des applications 
objet. Au milieu des annees 90, plusieurs dizaines de methodes objet sont disponibles, mais 
aucune ne predomine. L'unification et la normalisation des trois methodes dominantes, a 
savoir Booch, du nom de son auteur, OOSE {Object Oriented Software Engineering), d'lvan 
Jacobson et OMT (Object Modeling Technique), de James Rumbaugh, sont a Forigine de la 
creation du langage UML (Unified Modeling Language). 

UML est une notation graphique concue pour representer, specifier, construire et documenter 
les systemes logiciels. Ses deux principaux objectifs sont la modelisation de systemes utili- 
sant les techniques orientees objet, depuis la conception jusqu'a la maintenance, et la crea- 
tion d'un langage abstrait comprehensible par l'homme et interpretable par les machines. 
UML s'adresse a toutes les personnes chargees de la production, du deploiement et du suivi 
de logiciels (analystes, developpeurs, chefs de projets, architectes...), mais peut egalement 
servir a la communication avec les clients et les utilisateurs du logiciel. II s'adapte a tous les 
domaines d'application et a tous les supports. II permet de construire plusieurs modeles 
d'un systeme, chacun mettant en valeur des aspects differents : fonctionnels, statiques, dyna- 
miques et organisationnels. UML est devenu un langage incontournable dans les projets de 
developpement. 

Une methode de developpement definit a la fois un langage de modelisation et la marche a 
suivre lors de la conception. Le langage UML propose uniquement une notation dont 
Interpretation est definie par un standard, mais pas une methodologie complete. Plusieurs 
processus de developpement complets fondes sur UML existent, comme le Rational Unified 
Process (RUP), de Booch, Jacobson et Rumbaugh, ou l'approche MDA (Model Driven 
Architecture) proposee par l'OMG, mais ils ne font pas partie du standard UML. 
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Le processus RUP propose de bien maitriser les etapes successives de la modelisation et du 
developpement par une approche iterative. L'approche MDA propose une architecture 
du developpement en deux couches : le PIM (Platform Indepent Model) represente une 
vision abstraite du systeme, independante de l'implementation ; le PSM (Platform Specific 
Model) represente les programmes executables, qui doivent etre obtenus en partie automati- 
quement a partir du PIM ; a cela s'ajoute le PDM (Platform Definition Model), en l'occurrence 
une description de l'architecture physique voulue (langages de programmation, architecture 
materielle...). 

UML integre de nombreux concepts permettant la generation de programmes. C'est un 
langage de modelisation fonde sur des evenements ou des messages. II ne convient pas pour 
la modelisation de processus continus, comme la plupart des precedes en physique. Ce n'est 
pas un langage formel, ni un langage de programmation. II ne peut pas etre utilise pour valider 
un systeme, ni pour generer un programme executable complet. Mais, il permet de produire 
des parties de code, comme le squelette des classes (attributs et signatures de methode). 
Meme si la version 2 apporte des avancees significatives au niveau du formalisme, UML n'a 
pas encore atteint la rigueur syntaxique et semantique des langages de programmation. 

UML est le resultat d'un large consensus, continuellement enrichi par les avancees en 
matiere de modelisation de systemes et de developpement de logiciels. C'est le resultat d'un 
travail d'experts reconnus, issus du terrain. II couvre toutes les phases du cycle de vie de 
developpement d'un systeme et se veut independant des langages d'implementation et des 
domaines d'application. 

Historique du langage UML 

A la fin des annees 80, l'industrie commence a utiliser massivement les langages de program- 
mation orientes objet, tels que C++, Objective C, Eiffel et Smalltalk. De l'industrialisation 
de ce type de programmation est ne le besoin de « penser objet », independamment du 
langage d'implementation. Plusieurs equipes proposent alors des methodes (OMT, OOSE, 
Booch, Coad, Odell, CASE...) qui, pour la plupart, modelisent les memes concepts fonda- 
mentaux dans differents langages, avec une terminologie, des notations et des definitions 
differentes. Les differents protagonistes conviennent rapidement du besoin d'unifier ces 
langages en un standard unique. 

Lors de la conference OOPSLA d'octobre 1995, Booch et Rumbaugh presentent la version 
0.8 de leur methode unifiee (Unified Method 0.8). lis sont rejoints la meme annee par 
Jacobson. Les trois auteurs ameliorent la methode unifiee et proposent en 1996 la version 
0.9 du langage UML. Rational Software, qui emploie desormais le trio, publie en 1997 la 
documentation de la version 1.0 d'UML et la propose a l'OMG en vue d'une standardi- 
sation. Des modifications sont apportees a la version proposee par Rational, puis l'OMG 
propose, la meme annee, la version UML 1.1, qui devient un standard. 

L'OMG constitue ensuite un groupe de revision nomme RTF (Revision Task Force). Entre- 
temps, de tres nombreux utilisateurs industriels adoptent UML et apportent quelques 
modifications, ce qui conduit a la proposition de la version 1.2 en 1999. La premiere revision 
significative du langage est la version 1.3, proposee en 1999, dont la specification complete 
est publiee en mars 2000. En mars 2003, la version 1.5 voit le jour. 

Concretement, UML 1 est utilise lors de la phase d'analyse et de conception preliminaire des 
systemes. II sert a specifier les fonctionnalites attendues du systeme (diagrammes de cas 
d'utilisation et de sequence) et a decrire l'architecture (diagramme de classes). La descrip- 
tion de la partie comportementale (diagrammes d'activites et d'etats) est moins utilisee. 
Cela est du essentiellement a l'insuffisance de la formalisation de la conception detaillee 
dans UML 1. La plupart du temps, en matiere de specification des algorithmes et des 
methodes de traitement, le seul moyen est de donner une description textuelle informelle. 
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Certes, des outils comme les automates et les diagrammes d'activites sont disponibles, mais 
leur emploi est limite. Les utilisateurs restent sur le vieux paradigme centre sur le code : ils 
se contentent de recourir a UML lors des phases preliminaries et passent a un langage de 
programmation classique lors des phases de codage et de tests. L'un des objectifs de l'OMG 
est de proposer un paradigme guide par des modeles decrivant a la fois le codage, la gestion 
de la qualite, les tests et verifications, et la production de la documentation. II s'agit de 
recentrer l'activite des informaticiens sur les fonctions que le systeme doit fournir, en 
conformite avec les exigences du client et les standards en vigueur. 

Objectif du livre 

L'objectif de cet ouvrage est de fournir une reference concise des concepts de base d'UML, 
illustree par de nombreux exemples. Nous adoptons le point de vue pragmatique des utili- 
sateurs du langage. II permet de comprendre l'importance de la modelisation et l'interet 
d'employer une notation graphique. 

Selon le principe de cette collection, chaque chapitre commence par une synthese de cours 
presentant les concepts de base du langage, avec leur syntaxe precise, et illustree de nom- 
breux exemples, remarques pratiques et commentaires. Vient ensuite une serie d'exercices. 

Ce livre donne la vue utilisateur des concepts de la notation UML : ils sont decrits avec pre- 
cision dans la norme par un metamodele, mais cet aspect un peu complexe n'est pas detaille 
dans cet ouvrage. 

Le langage UML ne s'appuie pas sur un processus decrivant les etapes du developpement. 
Cependant, il est bien adapte aux processus iteratifs guides par les besoins des utilisateurs et 
axes sur l'architecture. Les exemples et les exercices corriges, presentes au fil des chapitres, 
donnent des indications sur les approches a suivre pour elaborer un modele d'une situation 
donnee. Le probleme difficile et recurrent de l'enchainement des modeles est traite dans 
une etude de cas presentee au chapitre 6. 

Structure du livre 

Le livre est compose de chapitres qui peuvent etre lus separement. Cependant, le plan res- 
pecte toujours la meme demarche dont la premiere etape correspond a une presentation du 
point de vue fonctionnel. L' analyse fonctionnelle permet de mettre au point une represen- 
tation graphique, compacte et complete des besoins, appelee « diagramme de cas d' utilisa- 
tion ». Les cas sont eventuellement decrits textuellement afin de specifier les differents 
scenarios attendus du systeme. Vient ensuite la partie « analyse statique », dans laquelle on 
specifie les classes et les relations entre classes (diagramme de classes). Des cas particuliers 
ou explicatifs sont aussi presentes par des diagrammes d'objets. Une fois que les differents 
objets sont definis (diagramme de classes), on revient sur l'analyse fonctionnelle dans 
laquelle on specifie les interactions entre les differents objets du systeme. On peut etre inte- 
resse par les echanges dans le temps (diagramme de sequence) ou encore par les collabo- 
rations existantes entre les objets (diagramme de communication). La description de la 
partie dynamique du systeme est presentee par les diagrammes d'etats et les diagrammes 
d'activites. 

Chaque chapitre est divise en deux parties : le rappel de cours puis les exercices corriges, qui 
occupent une part importante de l'ouvrage. Ils illustrent via des exemples simples les 
concepts presentes dans le rappel de cours et expliquent comment utiliser UML dans des 
situations pratiques. Ils donnent quelques indications sur la maniere de modeliser (ce qui 
ne fait pas partie de la description du langage). A travers une application concrete, le chapi- 
tre 6 introduit le diagramme de composants, qui permet une organisation statique du sys- 
teme, et presente une methodologie complete integrant la plupart des concepts presentes 
dans les chapitres precedents. 
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Prerequis 

Si cet ouvrage peut etre aborde par toute personne ayant une certaine culture informatique, 
certains passages necessitent la connaissance des notions minimales de programmation 
objet. De nombreux concepts d'UML (classes, heritage, encapsulation...) sont directement 
proposes par les langages de programmation orientes objet, comme le C++ ou Java. Certains 
exemples sont done compares a ces langages, et supposent done une experience minimale 
de la programmation orientee objet. Les ouvrages sur le C++ et Java 5, publies dans la 
meme collection, sont de bonnes references en la matiere. 

Pourquoi modeliser ? 

Un modele est une representation simplifiee d'une realite. II permet de capturer des aspects 
pertinents pour repondre a un objectif defini a priori. Par exemple, un astronaute modeli- 
sera la Lune comme un corps celeste ayant une certaine masse et se trouvant a une certaine 
distance de la Terre, alors qu'un poete la modelisera comme une dame avec laquelle il peut 
avoir une conversation. 

Le modele s'exprime sous une forme simple et pratique pour le travail [Rumbaugh2004]. 
Quand le modele devient complique, il est souhaitable de le decomposer en plusieurs 
modeles simples et manipulables. 

L'expression d'un modele se fait dans un langage compatible avec le systeme modelise et les 
objectifs attendus. Ainsi, le physicien qui modelise la lune utilisera les mathematiques 
comme langage de modelisation. Dans le cas du logiciel, Fun des langages utilises pour la 
modelisation est le langage UML. II possede une semantique propre et une syntaxe compo- 
ses de graphique et de texte et peut prendre plusieurs formes (diagrammes). 

Les modeles ont differents usages : 

• lis servent a circonscrire des systemes complexes pour les dominer. Par exemple, il est ini- 
maginable de construire une fusee sans passer par une modelisation permettant de tester 
les reacteurs, les procedures de securite, l'etancheite de l'ensemble, etc. 

• lis optimisent Forganisation des systemes. La modelisation da la structure d'une entre- 
prise en divisions, departements, services, etc. permet d' avoir une vision simplifiee du 
systeme et par la meme d'en assurer une meilleure gestion 

• lis permettent de se focaliser sur des aspects specifiques d'un systeme sans s'embarrasser 
des donnees non pertinentes. Si l'on s'interesse a la structure d'un systeme afin de facto- 
riser ses composants, il est inutile de s'encombrer de ses aspects dynamiques. En utilisant, 
par exemple, le langage UML, on s'interessera a la description statique (via le diagramme 
de classes) sans se soucier des autres vues. 

• lis permettent de decrire avec precision et completude les besoins sans forcement connaitre 
les details du systeme. 

• lis facilitent la conception d'un systeme, avec notamment la realisation de maquette 
approximative, a echelle reduite, etc. 

• lis permettent de tester une multitude de solutions a moindre cout et dans des delais 
reduits et de selectionner celle qui resout les problemes poses. 

La modelisation objet produit des modeles discrets permettant de regrouper un ensemble 
de configurations possibles du systeme et pouvant etre implemented dans un langage de 
programmation objet. La modelisation objet presente de nombreux avantages a travers 
un ensemble de proprietes (classe, encapsulation, heritage et abstraction, paquetage, 
modularite, extensibilite, adaptabilite, reutilisation) qui lui confere toute sa puissance et 
son interet. 
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Figure 0.1 

Organisation 

en quatre couches 

du langage UML. 



UML2 

UML 2 apporte des evolutions majeures par rapport a UML 1.5, sans toutefois etre revolu- 
tionnaire : les principales fonctionnalites de base se ressemblent. Au niveau du metamodele, 
qui concerne surtout les developpements d'outils, UML 2 se rapproche davantage des stan- 
dards de modelisation objet proposes par FOMG. En particulier, 1'unification du noyau 
UML et des parties conceptuelles de modelisation MOF (Meta-Object Facility) permet aux 
outils MOF de gerer les modeles UML ; l'ajout du principe de profils permet de mieux defi- 
nir les extensions du domaine ; enfin, la reorganisation du metamodele UML elimine les 
redondances presentes dans les versions precedentes (voir la fin de l'ouvrage pour plus de 
details concernant la structuration du langage UML). 

Du point de vue de l'utilisateur, les changements concernent certaines notations. La nota- 
tion des diagrammes de sequence se rapproche de la norme d'echanges de messages MSC 
(Message Sequence Chart) de 1'IUT (Union Internationale des Telecommunications). Le concept 
de classeurs s'inspire des avancees de l'ingenierie temps reel du langage de description et de 
specification SDL. De plus, UML 2 unifie la modelisation des activites et la modelisation des 
actions introduites dans UML 1.5 et utilise des notations de modelisation de processus 
metier. Des elements de modelisation contextuels ameliorent la souplesse et formalisent 
mieux le concept d'encapsulation des classes et des collaborations. 

Afin de formaliser le modele utilisateur du langage et de le rapprocher davantage des normes 
OMG, le langage UML est structure en quatre couches (figure 0.1) ; seules les deux couches 
user model et run time instance sont destinees a l'utilisateur. 
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L'utilisateur n'a pas besoin de mettre en evidence cette organisation quand il utilise UML. II 
doit se contenter de respecter la syntaxe et la semantique du langage detaillees dans ce livre. 
II doit egalement connaitre les differents diagrammes mettant en valeur tantot des aspects 
statiques, tantot des aspects comportementaux du systeme. Une organisation conceptuelle 
des differents diagrammes UML permet d'avoir une vision plus claire des vues offertes par 
ce langage. Les trois auteurs a l'origine du langage UML proposent un decoupage concep- 
tuel en quatre domaines : structured dynamique, physique et gestion de modeles (voir la fin 
de l'ouvrage pour plus de details). 
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UML permet de construire plusieurs modeles d'un systeme : 
certains montrent le systeme du point de vue des utilisateurs, 
d'autres montrent sa structure interne, d'autres encore en 
donnent une vision globale ou detaillee. Les modeles se 
completent et peuvent etre assembles, lis sont elabores tout 
au long du cycle de vie du developpement d'un systeme 
(depuis le recueil des besoins jusqu'd la phase de 
conception). Dans ce chapitre, nous allons etudier un 
des modeles, en I'occurrence le premier d construire : 
le diagramme de cas d'utilisation. Il permet de recueillir, 
d'analyser et d'organiser les besoins. Avec lui debute 
I'etape d'analyse d'un systeme. 
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□ ^importance de bien recueillir les besoins 



Le developpement d'un nouveau systeme, ou F amelioration d'un systeme existant, doit 
repondre aunoua plusieurs besoins. Par exemple, une banque a besoin d'un guichet auto- 
matique pour que ses clients puissent retirer de Fargent meme en dehors des heures 
d'ouverture de la banque. Celui qui commande le logiciel est le maitre d'ouvrage. Celui qui 
realise le logiciel est le maitre d'ceuvre. 

Le maitre d'ouvrage intervient constamment au cours du projet, notamment pour : 

• definir et exprimer les besoins ; 

• valider les solutions proposees par le maitre d'ceuvre ; 

• valider le produit livre. 

Le maitre d'ceuvre est, par exemple, une societe de services en informatique (SSII). II a ete 
choisi, avant tout, pour ses competences techniques. Mais son savoir-faire va bien au-dela. 
Au debut du projet, il est capable de recueillir les besoins aupres du maitre d'ouvrage. Le 
recueil des besoins implique une bonne comprehension des metiers concernes. Realiser un 
logiciel pour une banque, par exemple, implique la connaissance du domaine bancaire et 
l'integration de toutes les contraintes et exigences de ce metier. Cette condition est neces- 
saire pour bien cerner les cas d'utilisation exprimes par le client arm d'apporter les solutions 
adequates. 

Chaque cas a ses particularites liees au metier du client. Le recueil des besoins peut s'operer 
de differentes facons. Cela dit, il est recommande de completer le cahier des charges par des 
discussions approfondies avec le maitre d'ouvrage et les futurs utilisateurs du systeme. II 
convient egalement d'utiliser tous les documents produits a propos du sujet (rapports tech- 
niques, etude de marche...) et d'etudier les procedures administratives des fonctions de 
l'entreprise qui seront prises en charge par le systeme. La question que doit se poser le 
maitre d'ceuvre durant le recueil des besoins est la suivante : ai-je toutes les connaissances 
et les informations pour definir ce que doit faire le systeme ? 
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2.1 Les cas d'utilisation 



Parlons a present d'UML et voyons quelle aide il peut apporter lors du recueil des besoins. 
UML n'est qu'un langage et il ne sert ici qua formaliser les besoins, c'est-a-dire a les 
representor sous une forme graphique suffisamment simple pour etre comprehensible par 
toutes les personnes impliquees dans le projet. N'oublions pas que bien souvent, le maitre 
d'ouvrage et les utilisateurs ne sont pas des informaticiens. II leur faut done un moyen sim- 
ple d'exprimer leurs besoins. C'est precisement le role des diagrammes de cas d'utilisation. 
lis permettent de recenser les grandes fonctionnalites d'un systeme. 



EXEMPLE La figure 1 .1 modelise une borne interactive qui permet d'acceder d une banque. Le systeme 

d modeliser apparaTt dans un cadre (cela permet de separer le systeme d modeliser du 
monde exterieur). Les utilisateurs sont representes par des petits bonshommes, et les grandes 
fonctionnalites (les cas d'utilisation) par des ellipses. 
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Figure 1 .1 

Diagramme 
de cas d'utilisation 
modelisant une 
borne d'acces 
a une banque. 
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L'ensemble des cas d'utilisation contenus dans le cadre constitue « un sujet ». Les petits 
bonshommes sont appeles « acteurs ». lis sont connectes par de simples traits (appeles 
« associations ») aux cas d'utilisation et mettent en evidence les interactions possibles entre 
le systeme et le monde exterieur. Chaque cas modelise une facon particuliere et coherente 
d'utiliser un systeme pour un acteur donne. 



Definition 

Un cas d'utilisation est une maniere specifique d'utiliser un systeme. Les acteurs sont d 
I'exterieur du systeme ; ils modelisent tout ce qui interagit avec lui. Un cas d'utilisation 
realise un service de bout en bout, avec un declenchement, un deroulement et une fin, pour 
I'acteur qui I'initie. 



Notation et specification 

Un cas d'utilisation se represente par une ellipse (figure 1 .2). Le nom du cas est inclus dans 

I'ellipse ou bien il figure dessous. Un stereotype (voir la definition ci-apres), peut etre ajoute 

optionnellement au-dessus du nom, et une liste de proprietes placee au-dessous. 

Un cas d'utilisation se represente aussi sous la forme d'un rectangle a deux compartiments : 

celui du haut contient le nom du cas ainsi qu'une ellipse (symbole d'un cas d'utilisation) ; 

celui du bas est optionnel et peut contenir une liste de proprietes (figure 1 .3). 

Un acteur se represente par un petit bonhomme ayant son nom inscrit dessous (figure 1 . 1 ) ou 

par un rectangle contenant le stereotype acteur avec son nom juste en dessous (figure 1 .4). 

II est recommande d'ajouter un commentaire sur I'acteur pour preciser son role. 



Figures 1 .2 et 1 .3 

Representations 
d'un cas 
d'utilisation. 




« stereotype » ^N. 
Nom du cas J 
Liste de proprietes J 



Nom du cas CZ5 



Liste de proprietes 



Figure 1 .4 

Autre representation 
d'un acteur. 



Role de I'acteur 



« acteur » 
Nom de I'acteur 



Diagramme de cas d'utilisation 



La figure 1.4 represente un acteur par un rectangle. UML utilise aussi les rectangles pour 
representer des classes, et plus generalement des classeurs. Pour autant, la notation n'est pas 
ambigue puisque le stereotype acteur indique que le rectangle designe un acteur. Les stereo- 
types permettent d'adapter le langage a des situations particulieres. 



Definition 

Un stereotype represente une variation d'un element de modele existant. 

A un niveau d'abstraction plus eleve, UML permet de representer tous les cas d'utilisation 
d'un systeme par un simple rectangle. La figure 1.5 montre comment un tel rectangle peut 
remplacer tous les cas d'utilisation de la figure 1.1. 



Figure 1 .5 

Representation des cas 
d'utilisation a un niveau 
d'abstraction eleve. 



Borne interactive d'une banque 



Le rectangle de la figure 1.5 est appele « classeur ». 



Definition 




Un classeur est un element de modelisation qui decrit une unite comportementale ou struc- 
tured. Les acteurs et les cas d'utilisation sont des classeurs. Tout au long de ce livre, on 
retrouvera le terme « classeur » car cette notion englobe aussi les classes, des parties d'un 
systeme, etc. 



Notation 

Un classeur se represente par un rectangle contenant eventuellement des compartiments (la 
figure 1 .6 montre comment il est possible de faire figurer explicitement des cas d'utilisation 
dans un classeur). 



Figure 1 .6 

Les compartiments 
d'un classeur. 



Borne interactive d'une banque 




^fec^er^nvireme^ 



^Consulter comptes^ 
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2.2 Relations entre acteurs et cas d'utilisation 



EXEMPLE 



Figure 1 .7 

Association avec 
multiplicite. 



Un acteur peut utiliser plusieurs fois le meme cas d'utilisation. 

La figure 1 .7 montre un internaute qui telecharge plusieurs morceaux de musique sur Internet. 



Internaute 



Logiciel de telechargement 




Telecharger une musique 




Le symbole * qui signifie « plusieurs » est ajoute a l'extremite du cas et s'appelle une multi- 
plicite. Plusieurs valeurs sont possibles pour la multiplicite : exactement n s'ecrit tout sim- 
plement n, m..n signifie entre m et n, etc. Preciser une multiplicite sur une relation 
n'implique pas necessairement que les cas sont utilises en meme temps. 



2.3 Relations entre cas d'utilisation 



Pour clarifier un diagramme, UML permet d'etablir des relations entre les cas d'utilisation. 
II existe principalement deux types de relations : les dependances stereotypies et la genera- 
lisation/specialisation. Les dependances stereotypies sont des dependances dont la portee 
est explicitee par le nom du stereotype. Les stereotypes les plus utilises sont l'inclusion et 
l'extension. 

• La relation d'inclusion. Un cas A est inclus dans un cas B si le comportement decrit par le 
cas A est inclus dans le comportement du cas B : on dit alors que le cas B depend de A. 
Cette dependance est symbolisee par le stereotype inclut. Par exemple, Faeces aux infor- 
mations d'un compte bancaire inclut necessairement une phase d'authentification avec 
un mot de passe (figure 1.8). 

• La relation d'extension. Si le comportement de B peut etre etendu par le comportement 
de A, on dit alors que A etend B. Une extension est souvent soumise a condition. Graphi- 
quement, la condition est exprimee sous la forme d'une note. La figure 1.8 presente 
l'exemple d'une banque oil la verification du solde du compte n'intervient que si la 
demande de retrait d' argent depasse 20 euros. 

• La relation de generalisation. Un cas A est une generalisation d'un cas B si B est un cas 
particulier de A. A la figure 1.8, la consultation d'un compte bancaire via Internet est un 
cas particulier de la consultation. Cette relation de generalisation/specialisation est pre- 
sente dans la plupart des diagrammes UML et se traduit par le concept d'heritage dans les 
langages orientes objet. 

Les inclusions permettent aussi de decomposer un cas complexe en sous-cas plus simples. 



EXEMPLE A la figure 1 .9, le modelisateur a juge que la vente d'un article par correspondence est un 

probleme complexe et qu'il est important de faire apparaTtre dans le modele une decomposi- 
tion en sous-cas. 



Diagramme de cas d'utilisation 



Notation et specification 

Une dependance se represente par une fleche pointillee. Un stereotype est souvent ajoute 
au-dessus du trait. 

Le stereotype inclut indique que la relation de dependance est une inclusion (figures 1 .8 
et 1.9). 

Le stereotype etend indique une extension (figure 1 .8). L'extension peut intervenir d un point 
precis du cas etendu ; ce point s'appelle le point d'extension ; il porte un nom, qui figure 
dans un compartiment du cas etendu sous la rubrique « point d'extension », et est eventuelle- 
ment associe a une contrainte indiquant le moment ou l'extension intervient. Une extension 
est souvent soumise d une condition (indiquee dans une note attachee d la fleche pointillee). 
Le symbole utilise pour la generalisation est une fleche en traits pleins dont la pointe est un 
triangle ferme. La fleche pointe vers le cas le plus general (figure 1 .8). 





Figure 1 .9 

Relations entre cas 
pour decomposer 
un cas complexe. 



Prepose aux 
commandes 



Systeme de vente par correspondance 



Verifier la disponibilite 
de l'article 

y << inclut 



-(^I>asseriine commande^ 



" s, « inclut > 




Verifier la solvability du client 




Un cas relie a un autre cas peut ne pas etre directement accessible a un acteur (figure 1.9). 
Un tel cas est appele « cas interne ». 



UML2 



Chapitre 



Definition 




Un cas d'utilisation est dit « interne » s'il n'est pas relie directement d un acteur. 

Les relations entre cas ne sont pas obligatoires. Elks permettent de clarifier et d'enrichir les 
cas d'utilisation. Par exemple, a la figure 1.8, rien n'empeche de regrouper les cas « Consulter 
comptes » et « Consulter sur Internet » en un seul cas. Cependant, indiquer des la phase de 
recueil des besoins qu'il y a des cas particuliers apporte une information supplementaire 
pertinente. La question a se poser est : faut-il la faire figurer dans le diagramme de cas d'uti- 
lisation ou la prendre en compte plus tard ? La reponse a cette question ne sera pas toujours 
la meme selon le contexte du projet. 



Remarque 

Attention d I'orientation des fleches : si le cas A inclut B on trace la fleche de A vers B, mais 
si B etend A, la fleche est dirigee de B vers A. 



2.4 Relations entre acteurs 



La seule relation possible entre deux acteurs est la generalisation : un acteur A est une 
generalisation d'un acteur B si l'acteur A peut etre substitue par l'acteur B (tous les cas d'uti- 
lisation accessibles a A le sont aussi a B, mais l'inverse n'est pas vrai). 



EXEMPLE La figure 1 .10 montre que le directeur des ventes est un prepose aux commandes avec un 

pouvoir supplementaire (en plus de pouvoir passer et suivre une commande, il peut gerer le 
stock). Le prepose aux commandes ne peut pas gerer le stock. 



Figure 1.10 

Relations 
entre acteurs. 



Prepose aux 
commandes 



Directeur 
des ventes 



Systeme de vente par correspondance 




Passer une commande 




« inclut » 
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Notation 

Le symbole utilise pour la generalisation entre acteurs est une fleche en traits pleins dont la 
pointe est un triangle ferme. La fleche pointe vers I'acteur le plus general. 




2.5 Regroupement des cas d'utilisation en paquetages 



UML permet de regrouper des cas d'utilisation dans une entite appelee « paquetage ». Le 
regroupement peut se faire par acteur ou par domaine fonctionnel. Un diagramme de cas 
d'utilisation peut contenir plusieurs paquetages et des paquetages peuvent etre inclus dans 
d'autres paquetages. 



Definition 

Un paquetage permet d'organiser des elements de moderation en groupe. Un paquetage 
peut contenir des classes, des cas d'utilisations, des interfaces, etc. 



EXEMPLE A la figure 1.11, trois paquetages ont ete crees : Client, Stock et Support. Ces paquetages 

contiennent les cas d'utilisation du diagramme de la figure 1.10 (Client contient les cas 
« Passer une commande » et « Suivre une commande », Stock contient le cas « Gerer le 
stock », tandis que le cas « Rechercher article » est inclus dans le paquetage Support. 



Figure 1.11 

Regroupement 
des cas d'utilisation 
en paquetage. 



Client 



Dependance 
entre paquetages 

qui reflete 
l'inclusion des 
cas d'utilisation. 



Stock 



Support 









En tant que langage, UML est soumis a des regies de nommage qu'il faut strictement respec- 
ter : pour acceder au contenu de paquetages imbriques les uns dans les autres, il faut utiliser 
des deux-points comme separateur des noms de paquetage. Par exemple, si un paquetage B 
inclus dans un paquetage A contient une classe X, il faut ecrire A::B::X pour pouvoir utiliser 
la classe X en dehors du contexte des paquetages. 
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0 Modelisation des besoins avec UML 

3.1 Qui sont les acteurs ? Comment les identifier ? 



Les principaux acteurs sont les utilisateurs du systeme. lis sont en general faciles a reperer. 
C'est le maitre d'ouvrage qui les designe. Chaque acteur doit etre nomme, mais attention, 
pour trouver son nom, il faut penser a son role : un acteur represente un ensemble coherent 
de roles joues vis-a-vis d'un systeme. Ainsi, pour un logiciel de gestion de paie, le nom 
correct d'un acteur est Comptable plutot que Mme Dupont. Plusieurs personnes peuvent 
avoir le meme role. C'est le cas des clients d'une banque par exemple. II n'y aura alors qu'un 
seul acteur. Reciproquement, une meme personne physique peut jouer des roles differents 
vis-a-vis du systeme et done correspondre a plusieurs acteurs. 

En general, les utilisateurs ne sont pas difficiles a trouver, mais il faut veiller a ne pas oublier 
les personnes responsables de l'exploitation et de la maintenance du systeme. Par exemple, 
un logiciel de surveillance qui limite les acces a un batiment doit avoir un administrateur 
charge de creer des groupes de personnes et leur donner des droits d'acces. II ne s'agit pas ici 
des personnes qui installent et parametrent le logiciel avant sa mise en production, mais des 
utilisateurs du logiciel dans son fonctionnement nominal. 

En plus des utilisateurs, les acteurs peuvent etre : 

• des peripheriques manipules par le systeme (imprimantes, robots. . . ) ; 

• des logiciels deja disponibles a integrer dans le projet ; 

• des systemes informatiques externes au systeme mais qui interagissent avec lui, etc. 

Pour faciliter la recherche des acteurs, on peut imaginer les frontieres du systeme. Tout ce 
qui est a l'exterieur et qui interagit avec le systeme est un acteur ; tout ce qui est a l'interieur 
est une fonctionnalite du systeme que le maitre d'oeuvre doit realiser. 

Un cas d'utilisation a toujours au moins un acteur principal pour qui le systeme produit un 
resultat observable, et eventuellement d'autres acteurs ayant un role secondaire. Par exem- 
ple, l'acteur principal d'un cas de retrait d'argent dans un distributeur automatique de 
billets est la personne qui fait le retrait, tandis que la banque qui verifie le solde du compte 
est un acteur secondaire. En general, l'acteur principal initie le cas d'utilisation par ses solli- 
citations. 

Definition 

L'acteur est dit « principal » pour un cas d'utilisation lorsque le cas d'utilisation rend service 
d cet acteur. Les autres acteurs sont dits « secondaires ». Un cas d'utilisation a au plus un 
acteur principal, et un ensemble - eventuellement vide - d'acteurs secondaires. 
Un acteur principal obtient un resultat observable du systeme tandis qu'un acteur secon- 
daire est sollicite pour des informations complementaires. 
I ! 

3.2 Comment recenser les cas d'utilisation ? 



II n'y a pas une facon unique de reperer les cas d'utilisation. II faut se placer du point de vue 
de chaque acteur et determinez comment il se sert du systeme, dans quels cas il l'utilise, et a 
quelles fonctionnalites il doit avoir acces. II faut eviter les redondances et limiter le nombre de 
cas en se situant au bon niveau d'abstraction (par exemple, ne pas reduire un cas a une action). 




Diagramme de cas d'utilisation 



EXEMPLE Considerons un systeme de reservation et d'impression de billets de train via des bornes inter- 

actives situees dans des gares. En prenant pour acteur une personne qui souhaite obtenir un 
billet, on peut obtenir la liste suivante des cas d'utilisation : 

• rechercher un voyage ; 

• reserver une place dans un train ; 

• acheter son billet. 

L'ensemble des cas d'utilisation doit couvrir exhaustivement tous les besoins fonctionnels 
du systeme. L'etape de recueil des besoins est souvent longue et fastidieuse car les utilisateurs 
connaissent l'existant et n'ont qu'une vague idee de ce que leur apportera un futur systeme ; 
en outre, le cahier des charges contient des imprecisions, des oublis, voire des informations 
contradictoires difnciles a extraire. L' elaboration du diagramme de cas d'utilisation permet 
de pallier ces problemes en recentrant le systeme sur les besoins fonctionnels et ce, des le 
debut du projet. 

On peut se demander pourquoi adopter un point de vue fonctionnel, et non technique ? 
Trop souvent, par le passe, les logiciels etaient techniquement tres elabores sans pour autant 
satisfaire les utilisateurs. Avec les diagrammes de cas d'utilisation, on se place clairement du 
cote des utilisateurs. Le cote technique n'est pas oublie mais aborde differemment : les 
besoins sont affines lors de l'ecriture des specifications - on parle de specifications techni- 
ques des besoins (voir la section « Description textuelle des cas d'utilisation »). 



Remarque 

II ne faut pas faire apparaTtre les details des cas d'utilisation, mais il faut rester au niveau 
des grandes fonctions du systeme. La question qui se pose alors est de savoir jusqu'd quel 
niveau de details descendre ? Si le nombre de cas est trop important, il faut se demander 
si on a fait preuve de suffisamment d'abstraction. Le nombre de cas d'utilisation est un bon 
indicateur de la faisabilite d'un logiciel. 

II ne doit pas y avoir de notion temporelle dans un diagramme de cas d'utilisation. II ne faut 
pas se dire que I'acteur fait ceci, puis le systeme lui repond cela, ce qui implique une reac- 
tion de I'acteur, et ainsi de suite. Le sequencement temporel sera pris en compte plus tard, 
notamment dans la description detaillee des cas (voir section 3.3). 

L'interet des cas d'utilisation ne se limite pas au recueil des besoins. La description des cas 
d'utilisation peut servir de base de travail pour etablir les tests de verification du bon fonc- 
tionnement du systeme, et orienter les travaux de redaction de la documentation d I'usage 
des utilisateurs. 



3.3 Description des cas d'utilisation 



Le diagramme de cas d'utilisation decrit les grandes fonctions d'un systeme du point de vue 
des acteurs, mais n'expose pas de facon detaillee le dialogue entre les acteurs et les cas d'uti- 
lisation. 



EXEMPLE L'exemple de la figure 1.12 ne permet pas de savoir ce qui entre et ce qui sort du logiciel 

bancaire : le retrait d'argent se fait-il en euros ou en dollars ? Dans quel ordre les operations 
sont-elles effectuees ? Faut-il choisir le montant du retrait avant de choisir le compte d debiter, 
ou bien I'inverse ? Tous ces details sont des elements de specification. Specifier un produit, 
c'est le decrire de la facon la plus precise possible. 
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Figure 1.12 

Diagramme de cas 
d'utilisation pour 
une banque. 




Guichetier 



Gestion d'une banque 



Retirer argent 



Consulter compte 




Systeme 
central 



Les specifications peuvent etre divisees en deux categories selon qu'elles sont fonctionnelles 
ou techniques. Les specifications fonctionnelles concernent les fonctions du systeme, la 
fonction de retrait d'argent par exemple, tandis que les specifications techniques permettent 
de preciser le contexte d'execution du systeme. Par exemple, le logiciel qui gere la distribu- 
tion des billets doit etre compatible avec tel ou tel systeme d'exploitation, ou encore, un 
retrait d'argent doit se faire en moins de 5 secondes. 

Les specifications fonctionnelles decoulent directement du diagramme de cas d'utilisation. 
II s'agit de reprendre chaque cas et de le decrire tres precisement. En d'autres termes, vous 
devez decrire comment les acteurs interagissent avec le systeme. 



Exemple 



A partir du diagramme de cas d'utilisation de I'exemple precedent, la figure 1.13 montre une 
facon de decrire les interactions entre le guichetier et le systeme. On y voit clairement appa- 
raTtre une sequence de messages. 

Le graphisme utilise fait partie du formalisme des diagrammes de sequence (voir chapitre 3). 



Figure 1.13 

Description d'un cas 
d'utilisation par 
une sequence 
de messages. 
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Demande de validite du compte 



Compte valide 



Demande de debit du compte 



Compte debite 
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Les differentes facons de decrire les cas d'utilisation 

UML n'impose rien quant a la facon de decrire un cas d'utilisation. Au lieu d'utiliser une 
sequence de messages, il est possible d'utiliser les diagrammes d'activites d'UML (voir cha- 
pitre 5). Cette liberte de choix peut etre deroutante, mais comme UML est cense pouvoir 
modeliser tout type de systeme, une maniere unique de decrire un cas ne suffirait pas. 

Remarque 

Une des forces d 

mettent en avant des aspects dirterents d une description. Ainsi, le modelisdteur peut utiliser 
le type de diagramme qui lui pdraTt le plus dddpte pour representer son probleme (et so 
solution), tout en restont ddns Id norme. 

Description textuelle des cas d'utilisation 

Bien que de nombreux diagrammes d'UML permettent de decrire un cas, il est recommande 
de rediger une description textuelle car c'est une forme souple qui convient dans bien des 
situations. Une description textuelle couramment utilisee se compose de trois parties, comme 
le montre l'exemple suivant. La premiere partie permet d'identifier le cas. Elle doit contenir : 

• le nom du cas ; 

• un resume de son objectif ; 

• les acteurs impliques (principaux et secondaires) ; 

• les dates de creation et de mise a jour de la description courante ; 

• le nom des responsables ; 

• un numero de version. 

La deuxieme partie contient la description du fonctionnement du cas sous la forme d'une 
sequence de messages echanges entre les acteurs et le systeme. Elle contient toujours une 
sequence nominale qui correspond au fonctionnement nominal du cas (par exemple, un 
retrait d' argent qui se termine par l'obtention des billets demandes par l'utilisateur). Cette 
sequence nominale commence par preciser l'evenement qui declenche le cas (l'utilisateur 
introduit sa carte bancaire par exemple) et se developpe en trois points : 

• Les pre-conditions. Elles indiquent dans quel etat est le systeme avant que se deroule la 
sequence (le distributeur est alimente en billets par exemple). 

• L'enchamement des messages. 

• Les post-conditions. Elles indiquent dans quel etat se trouve le systeme apres le derouement 
de la sequence nominale (une transaction a ete enregistree par la ban que par exemple). 

Parfois la sequence correspondant a un cas a besoin d'etre appelee dans une autre sequence (par 
exemple quand une relation d'inclusion existe entre deux cas d'utilisation). Signifier l'appel 
d'une autre sequence se fait de la facon suivante : « appel du cas X », ou X est le nom du cas. 

Les acteurs n'etant pas sous le controle du systeme, ils peuvent avoir des comportements 
imprevisibles. La sequence nominale ne suffit done pas pour decrire tous les comporte- 
ments possibles. A la sequence nominale s'ajoutent frequemment des sequences alternatives 
et des sequences d'exceptions. Ces deux types de sequences se decrivent de la meme facon 
que la sequence nominale mais il ne faut pas les confondre. Une sequence alternative 
diverge de la sequence nominale (c'est un embranchement dans une sequence nominale) 
mais y revient toujours, alors qu'une sequence d'exception intervient quand une erreur se 
produit (le sequencement nominal s'interrompt, sans retour a la sequence nominale). 




e lo nototion UML est de proposer de nombreux types de diogrammes qui 
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EXEMPLE Dans le cas d'un retrait d'argent, des sequences alternatives se produisent par exemple dans 

les situations suivantes : 

• Le client choisit d'effectuer un retrait en euros ou en dollars. 

• Le client a la possibility d'obtenir un recu. 

Une exception se produit si la connexion avec le systeme central de la banque qui doit 
verifier la validite du compte est interrompue. 

La survenue des erreurs dans les sequences doit etre signalee de la facon suivante : « appel de 
l'exception Y » ou Y est le nom de l'exception. 

La derniere partie de la description d'un cas d'utilisation est une rubrique optionnelle. Elle 
contient generalement des specifications non fonctionnelles (ce sont le plus souvent des 
specifications techniques, par exemple pour preciser que Faeces aux informations bancaires 
doit etre securise). Cette rubrique contient aussi d'eventuelles contraintes liees aux interfaces 
homme-machine (par exemple, pour donner la possibilite d'acceder a tous les comptes d'un 
utilisateur a partir de l'ecran principal). 



Description d'un retrait d'argent 

Identification 

Nom du cas : retrait d'especes en euros. 
But : detaille les etapes permettant a un guichetier d'effectuer I'operation de retrait d'euros 
demande par un client. 
Acteur principal : Guichetier. 
Acteur secondaire : Systeme central. 
Date : le 18/02/2005. 
Responsable : M. Dupont. 
Version : 1 .0. 

Sequencement 

Le cas d'utilisation commence lorsqu'un client demande le retrait d'especes en euros. 
Pre-conditions 

Le client possede un compte (donne son numero de compte). 
Enchamement nominal 

1 . Le guichetier saisit le numero de compte client. 

2. L'application valide le compte aupres du systeme central. 

3. L'application demande le type d'operation au guichetier. 

4. Le guichetier selectionne un retrait d'especes de 200 euros. 

5. L'application demande au systeme central de debiter le compte. 

6. Le systeme notifie au guichetier qu'il peut delivrer le montant demande. 
Post-conditions 

Le guichetier ferme le compte. 
Le client recupere I'argent. 

Rubriques optionnelles 

Contraintes non fonctionnelles 

Fiabilite : les acces doivent etre extremement surs et securises. 

Confidentiality : les informations concernant le client ne doivent pas etre divulguees. 

Contraintes liees d I'interface homme-machine 

Donner la possibilite d'acceder aux autres comptes du client. 

Toujours demander la validation des operations de retrait. 
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La sequence nominale, les sequences alternatives, les exceptions, etc., font qu'il existe une 
multitude de chemins depuis le debut du cas jusqu'a la fin. Chaque chemin est appele 
« scenario ». Un systeme donne genere peu de cas d' utilisation, mais, en general, beaucoup 
de scenarios. 

Remarque 

Parfois, les utilisateurs ont du mal d decrire un cas sous une forme textuelle. II est alors 
judicieux de se servir d'une autre forme de description, en utilisant un organigramme ou 
encore en construisant des maquettes des interfaces homme-machine. Le dessin, meme som- 
maire, de I'aspect des ecrans des interfaces permet de fixer les idees ; il offre une excel- 
lente base pour la discussion avec le maTtre d'ouvrage, qui le considere comme plus 
« parlant ». 



Conclusion 

Les phases de recueil des besoins et d'ecriture des specifications sont longues et fastidieuses. 
Mais quand elles sont bien menees, elles permettent de lever toutes les ambiguites du cahier 
des charges et de recueillir les besoins dans leurs moindres details. Les specifications per- 
mettant d'approfondir les besoins (on parle d'ailleurs a juste titre de specifications techniques 
des besoins), la frontiere entre ces deux notions est floue. 

II n'est pas question a ce moment de la modelisation de limiter les besoins. Du cote du 
maftre d'oeuvre, la tendance est a les limiter a des fonctionnalites essentielles, tandis que 
le maitre d'ouvrage, et surtout les utilisateurs, ont tendance a en exprimer bien plus qu'il 
n'est possible d'en realiser. Le maitre d'oeuvre doit faire preuve ici de patience et mener la 
phase de specifications de tous les besoins jusqu'a son terme. C'est a ce moment seulement, 
que des priorites sont mises sur les specifications. Le maitre d'oeuvre tente alors d'agencer 
les besoins de facon coherente et fait plusieurs propositions de solutions au maitre 
d'ouvrage, qui couvrent plus ou moins de besoins. UML ne propose rien pour mettre des 
priorites sur les specifications. 

Le diagramme de cas d'utilisation est un premier modele d'un systeme. Que savons-nous 
sur le systeme apres avoir cree ce diagramme ? Sur le systeme lui-meme, en interne, pas 
grand-chose a vrai dire. C'est encore une boite noire a l'architecture et au mode de fonc- 
tionnement interne inconnus. Done, a fortiori, a ce stade, nous ne savons toujours pas com- 
ment le realiser. En revanche, son interface avec le monde qui l'entoure est partiellement 
connue : nous nous sommes places du point de vue des acteurs pour definir les specifica- 
tions fonctionnelles. II faut s'attarder un instant sur l'expression « partiellement connue » 
pour mesurer les limites du modele des cas d'utilisation. Les specifications fonctionnelles 
disent ce que le systeme doit faire pour les acteurs. En d'autres termes, nous connaissons pre- 
cisement ce qui entre et ce qui sort du systeme, mais, en revanche, nous ne savons toujours 
pas comment realiser cette interface avec l'exterieur. 



Cha 



L'objectif de cette phase de la modelisation est done de clairement identifier les frontieres du 
systeme et les interfaces qu'il doit offrir a l'utilisateur. Si cette etape commence avant la 
conception de l'architecture interne du systeme, il est en general utile, quand la reflexion est 
suffisamment poussee, de poser les bases de la structure interne du systeme, et done d'alter- 
ner analyse des besoins et ebauche des solutions envisagees. 

Aux specifications fonctionnelles s'ajoutent des specifications techniques qui peuvent etre 
vues comme des exigences pour la future realisation. 

Le present chapitre se poursuit par une serie de problemes corriges. Le chapitre 2, quant a 
lui, presente le diagramme des classes, qui permet de modeliser la structure interne d'un 
systeme. 
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Problemes 
et exercices 

La construction d'un diagramme de cas d'utilisation debute par la recherche des 
frontieres du systeme et des acteurs, pour se poursuivre par la decouverte des cas 
d'utilisation. L'ordre des exercices suit cette progression, ['elaboration proprement 
dite d'un diagramme de cas d'utilisation est illustree par plusieurs exercices. 
Ce chapitre se termine par des etudes de cas de complexites croissantes. 



Exercice 1 Identification des acteurs et recensement de cas d'utilisation 

SIMPLES 




Considerons le systeme informatique qui gere une station-service de distribution d' essence. 
On s'interesse a la modelisation de la prise d'essence par un client. 

1. Le client se sert de l'essence de la facon suivante. II prend un pistolet accroche a une 
pompe et appuie sur la gachette pour prendre de l'essence. Qui est Facteur du systeme ? 
Est-ce le client, le pistolet ou la gachette ? 

2. Le pompiste peut se servir de l'essence pour sa voiture. Est-ce un nouvel acteur ? 

3. La station a un gerant qui utilise le systeme informatique pour des operations de gestion. 
Est-ce un nouvel acteur ? 

4. La station-service a un petit atelier d'entretien de vehicules dont s'occupe un mecani- 
cien. Le gerant est remplace par un chef d'atelier qui, en plus d'assurer la gestion, est 
aussi mecanicien. Comment modeliser cela ? 



1. Pour le systeme informatique qui pilote la station-service, le pistolet et la gachette sont 
des peripheriques materiels. De ce point de vue, ce sont des acteurs. II est neanmoins 
necessaire de consigner dans le systeme informatique l'etat de ces peripheriques : des 
qu'un client prend le pistolet par exemple, le systeme doit informer le pompiste en indi- 
quant le type d'essence choisi. Pistolet et gachette doivent done faire partie du systeme a 
modeliser. Ici, nous sommes face a deux options contradictoires : soit le pistolet et la 
gachette sont des acteurs, soit ils ne le sont pas. Pour lever cette ambigui'te, il faut adopter 
le point de vue du client. Le client agit sur le systeme informatique quand il se sert de 
l'essence. L'action de se servir constitue une transaction bien isolee des autres fonction- 
nalites de la station-service. Nous disons done que « Se servir » est un cas d'utilisation. 

Le client, qui est en dehors du systeme, devient alors l'acteur principal, comme le montre 
la figure 1.14. Ce cas englobe la prise du pistolet et l'appui sur la gachette. Ces peripheri- 
ques ne sont plus considered comme des acteurs ; s'ils l'etaient, la modelisation se ferait a 
un niveau de details trop important. 
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Le client est done l'acteur principal du systeme. Or, bien souvent, le pompiste note le 
numero d'immatriculation du vehicule du client dans le systeme informatique. Le client 
doit alors etre modelise deux fois : la premiere fois en tant qu'acteur, et la seconde, a 
l'interieur du systeme, pour y conserver un numero d'immatriculation. 



Figure 1.14 

Le client comme 
acteur du cas 
« Se servir ». 



Client 



Station-service 



Se servir 



Figure 1.15 

Deux acteurs 
pour deux roles. 



2. Un acteur est caracterise par le role qu'il joue vis-a-vis du systeme. Le pompiste, bien 
qu'etant une personne differente du client, joue un role identique quand il se sert de 
l'essence. Pour le cas « Se servir », il n'est pas necessaire de creer un acteur supplemen- 
taire representant le pompiste. 

3. La gestion de la station-service definit une nouvelle fonctionnalite a modeliser. Le gerant 
prend le role principal ; e'est done un nouvel acteur (figure 1.15). 



Client 



Gerant 



Station-service 



Se servir 



Gerer la station 




Figure 1.16 
Relation 

de generalisation 
entre acteurs. 



La station offre un troisieme service : l'entretien des vehicules. Le systeme informatique 
doit prendre en charge cette fonctionnalite supplementaire. Un nouvel acteur apparait 
alors : le mecanicien. Le gerant est a present un chef d'atelier qui est un mecanicien ayant 
la capacite de gerer la station. II y a ainsi une relation de generalisation entre les acteurs 
Mecanicien et Chef d'atelier (figure 1.16) significant que le chef d'atelier peut, en plus 
d'assurer la gestion, entretenir des vehicules. 



Client 



Mecanicien 



Chef 
d'atelier 



Station-service 



Se servir 



Entretenir des vehicules 



Gerer la station 
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Exercice 2 Relations entre cas d'utilisation 



Enonce 



Figure 1.17 

Exemple d'un 

diagramme 

errone. 



Quel est le defaut du diagramme presente a la figure 1.17 ? 



Client 



Station-service 




Decrocher le pistolet j— (Appuyer sur la gachette 




Reposer le pistolet J— ( Payer 



Solution 



II ne faut pas introduire de sequencement temporel entre des cas d'utilisation (cette notion 
apparait lors de la description des cas). De plus, il est incorrect d'utiliser un trait plein pour 
relier deux cas. Cette notation est reservee aux associations entre les acteurs et les cas. 



Exercice 3 Relations entre cas d'utilisation - cas internes 



Enonce 



Figure 1.18 

Diagramme 
incomplet des 
cas d'utilisation 
d'une agence 
de voyages. 



Choisissez et dessinez les relations entre les cas suivants : 

1. Une agence de voyages organise des voyages ou l'hebergement se fait en hotel. Le client 
doit disposer d'un taxi quand il arrive a la gare pour se rendre a l'hotel. 




Agent de 
voyages 



Agence de voyages 



Reserver une 
chambre d' hotel 



Reserver un taxi 



Reserver un billet de train 



Organiser un voyage 



2. Certains clients demandent a l'agent de voyages d'etablir une facture detaillee. Cela donne 
lieu a un nouveau cas d'utilisation appele « Etablir une facture detaillee ». Comment 
mettre ce cas en relation avec les cas existants ? 

3. Le voyage se fait soit par avion, soit par train. Comment modeliser cela ? 



l.Le modelisateur a considere que l'organisation d'un voyage est trop complexe pour etre 
representee par un seul cas d'utilisation. II Fa done decomposed en trois taches modeli- 
sees par les trois cas d'utilisation « Reserver une chambre d'hotel », « Reserver un taxi » et 
« Reserver un billet de train ». Ces trois taches forment des transactions suffisamment 
isolees les unes des autres pour etre des cas d'utilisation. De plus, ces cas sont mutuellement 
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independants. lis constituent des cas internes du systeme car ils ne sont pas relies directe- 
ment a un acteur. 



Figure 1.19 

Relations d'inclusion 
entre cas d'utilisation. 



Agent de 
voyages 



Reserver une 
chambre d' hotel 



Agence de voyages 



Reserver un taxi 



« inclut » N 



« inclut » I 



Reserver un billet de train 



/ « inclut » 



Organiser un voyage 



2 .L'etablissement d'une facture detaillee se fait uniquement sur demande du client. Ce 
caractere optionnel est modelise par une relation d'extension entre les cas « Organiser un 
voyage » et « Etablir une facture detaillee ». L'extension porte la condition « a la demande 
du client ». 



Figure 1 .20 

Relation d'extension 
entre cas d'utilisation. 



Agent de 
voyages 



Agence de voyages 



Reserver une 
chambre d'hotel 




Reserver un billet de train 



Condition : { a la demande du ■ 



client} 

Point d'extension : etablirUneFacture 



I 

1 « etend > 

I 



Etablir une facture detaillee 



3. II y a maintenant deux cas particuliers : le voyage se fait en train ou en avion. Ces cas par- 
ticuliers sont modelises par les cas « Reserver un billet de train » et « Reserver un billet 
d'avion ». Ceux-ci sont lies a un cas plus general appele « Reserver un titre de transport ». 



Diagramme de cas d'utilisation 



19 




Exercice 4 Identification des acteurs, recensement des cas d'utilisation 
et relations simples entre cas 




Modelisez avec un diagramme de cas d'utilisation le fonctionnement d'un distributeur 
automatique de cassettes video dont la description est donnee ci-apres. 

Une personne souhaitant utiliser le distributeur doit avoir une carte magnetique speciale. 
Les cartes sont disponibles au magasin qui gere le distributeur. Elles sont creditees d'un 
certain montant en euros et rechargeables au magasin. Le prix de la location est fixe par 
tranches de 6 heures (1 euro par tranche). Le fonctionnement du distributeur est le sui- 
vant : le client introduit sa carte ; si le credit est superieur ou egal a 1 euro, le client est 
autorise a louer une cassette (il est invite a aller recharger sa carte au magasin sinon) ; le 
client choisit une cassette et part avec ; quand il la ramene, il l'introduit dans le distribu- 
teur puis insere sa carte ; celle-ci est alors debitee ; si le montant du debit excede le credit 
de la carte, le client est invite a regulariser sa situation au magasin et le systeme memorise 
le fait qu'il est debiteur ; la gestion des comptes debiteurs est prise en charge par le person- 
nel du magasin. On ne s'interesse ici qua la location des cassettes, et non a la gestion du 
distributeur par le personnel du magasin (ce qui exclut la gestion du stock des cassettes). 



Le seul acteur est le client. 

L'acquisition d'une carte et sa recharge ne se font pas via le distributeur : il faut aller au 
magasin. Ces fonctions ne donnent pas lieu a des cas d'utilisation. 

II ne faut pas faire apparaitre un sequencement temporel dans un diagramme de cas d'utili- 
sation. On ne fait done pas figurer les etapes successives telles que l'introduction de la carte 
puis le choix d'une cassette, etc. Ce niveau de details apparaitra quand on decrira les cas 
d'utilisation (sous forme textuelle par exemple). Dans un diagramme de cas d'utilisation, il 
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faut rester au niveau des grandes fonctions et penser en termes de transactions (une tran- 
saction est une sequence d'operations qui fait passer un systeme d'un etat coherent initial a 
un etat coherent final) . 

II n'y a done que deux cas : « Emprunter une video » et « Restituer une video » (figure 1.22). 



Figure 1 .22 

Diagramme de cas 
d'utilisation d'un 
distributee de 
cassettes video. 




Client 



Nom de l'acteur 


Role 


Client 


Represente un client du magasin de location de cassettes video. 



Pour decrire le cas « Emprunter une video », imaginons un scenario possible. Le client 
introduit sa carte. II doit ensuite pouvoir choisir une video. Quels sont les criteres de choix ? 
L'enonce ne precise pas ces criteres. Ce probleme arrive frequemment en situation reelle. 

Le maitre d'ouvrage dans un projet informatique de cette ampleur est bien souvent le pro- 
prietaire du magasin de location. II sait rarement rediger un cahier des charges. C'est le role 
du maitre d'oeuvre d'obliger le maitre d'ouvrage a bien formuler ses besoins. Choisir une 
video peut etre complexe : la recherche se fait-elle par genres, par titres ou par dates de sor- 
tie des films en salles ? Si la recherche se fait par genres, quels sont-ils ? Rechercher un film 
semble plus complexe qu'on ne l'imaginait au premier abord. De plus, cette fonctionnalite 
peut etre isolee de la location proprement dite, qui concerne plutot la gestion de la carte. 
Ces remarques incitent a creer le cas supplemental « Rechercher une video ». L'emprunt 
d'une video inclut sa recherche. Une relation d'inclusion intervient done entre les cas 
« Emprunter une video » et « Rechercher une video », comme le montre la figure 1.23. 



Figure 1 .23 

Diagramme de cas 
d'utilisation 
complete par la 
recherche d'une 
video. 



Client 



Magasin de location de cassettes video 




Emprunter une video ) . , . 
r y « inclut 



Restituer une video 



Rechercher une video 



A ce point de la modelisation, deux remarques s'imposent : 

• Le succes d'UML en tant que langage de modelisation s'explique, entre autres, par le fait 
qu'il oblige le modelisateur a poser les bonnes questions au bon moment ; la modelisa- 
tion vient a peine de commencer que deja des questions se posent. II faut cependant 
veiller a rester au niveau du recueil des besoins et des specifications et ne faire aucun 
choix de conception du systeme. II faut se contenter de decrire les fonctions du systeme 
sans chercher a savoir comment les realiser. 
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Le probleme des criteres de recherche a conduit a une revision du diagramme de cas 
d'utilisation. Cet « aller-retour » sur les modeles est necessaire. Chacun d'eux apporte des 
informations complementaires qui peuvent remettre en cause les modeles existants. Une 
fois tous les modeles etablis, la modelisation sera alors aboutie. 



Exercice 5 Description d'un cas d'utilisation 



Decrivez sous forme textuelle les cas d'utilisation « Emprunter une video » et « Rechercher 
une video » du diagramme presente a la figure 1.23. La recherche d'une video peut se faire 
par genres ou par titres de film. Les differents genres sont action, aventure, comedie et 
drame. Quand une liste de films s'affiche, le client peut trier les films par titres ou par dates 
de sortie en salles. 



Avant de presenter la solution, donnons quelques indications : 

• Tous les cas d'utilisation d'un systeme doivent etre decrits sous forme textuelle (dans la 
suite de ce chapitre, nous omettrons eventuellement de le faire pour des raisons de place 
ou d'interet). 

• Quand une erreur (exception) est detectee dans un cas, une sequence d'erreurs est activee 
(par exemple, voir la sequence El dans la description suivante). La sequence nominale 
n'est pas reprise et le cas s'interrompt aussitot. 



Description du cas « Emprunter une video » 

Identification 

Nom du cas : « Emprunter une video ». 
But : decrire les etapes permettant au client du magasin d'emprunter une cassette video via 
le distributeur automatique. 
Acteur principal : Client. 
Acteur secondaire : neant. 
Datede creation : le 31 /1 2/2004. 
Date de mise d jour : le 1/1/2005. 
Responsable : M. Dupont. 
Version : 1 . 1 . 




Sequencement 

Le cas d'utilisation commence lorsqu'un client introduit sa carte. 
Pre-conditions 

Le client possede une carte qu'il a achetee au magasin. 
Le distributeur est alimente en cassettes. 

Enchatnement nominal 

1 . Le systeme verifie la validite de la carte. 

2. Le systeme verifie que le credit de la carte est superieur ou egal a 1 euro. 

3. Appel du cas « Rechercher une video ». 

4. Le client a choisi une video. 

5. Le systeme indique, d'apres la valeur de la carte, pendant combien de temps (tranches 
de 6 heures) le client peut garder la cassette. 

6. Le systeme delivre la cassette. 
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Description du cas « Emprunter une video » [suite) 

7. Le client prend la cassette. 

8. Le systeme rend la carte au client. 

9. Le client prend sa carte. 

Enchatnements alternatifs 

Al : Le credit de la carte est inferieur a 1 euro. 

L'enchaTnement demarre apres le point 2 de la sequence nominale : 

3. Le systeme indique que le credit de la carte ne permet pas au client d'emprunter une 
video. 

4. Le systeme invite le client d aller recharger sa carte au magasin. 
La sequence nominale reprend au point 8. 

Enchatnements d'exception 

El : La carte introduite n'est pas valide. 

L'enchaTnement demarre apres le point 1 de la sequence nominale : 

2. Le systeme indique que la carte n'est pas reconnue. 

3. Le distributeur ejecte la carte. 

E2 : La cassette n'est pas prise par le client. 

L'enchaTnement demarre apres le point 6 de la sequence nominale : 

7. Au bout de 1 5 secondes le distributeur ovale la cassette. 

8. Le systeme annule la transaction (toutes les operations memorisees par le systeme sont 
defaites). 

9. Le distributeur ejecte la carte. 

E3 : La carte n'est pas reprise par le client. 

L'enchaTnement demarre apres le point 8 de la sequence nominale : 

9. Au bout de 1 5 secondes le distributeur ovale la carte. 
10. Le systeme consigne cette erreur (date et heure de la transaction, identifiant du client, 
identifiant du film). 

E4 : Le client a annule la recherche (il n'a pas choisi de video). 

L'enchaTnement demarre au point 4 de la sequence nominale : 

5. Le distributeur ejecte la carte. 

Post-conditions 

Le systeme a enregistre les informations suivantes : 

• La date et I'heure de la transaction, a la minute pres : les tranches de 6 heures sont cal- 
culees d la minute pres. 

• L'identifiant du client. 

• L'identifiant du film emprunte. 

Rubriques optionnelles 
Contraintes non fonctionnelles 

Le distributeur doit fonctionner 24 heures sur 24 et 7 jours sur 7. 

La verification de la validite de la carte doit permettre la detection des contrefacons. 

Contrainte liee a I'interface homme-machine 

Avant de delivrer la cassette, demander confirmation au client. 
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Description du cas « Rechercher une video » 

Identification 

Nom du cas : « Rechercher une video ». 
But : decrire les etapes permettant au client de rechercher une video via le distributeur auto- 
matique. 

Acteur principal : neant (cas interne inclus dans le cas « Emprunter une video »). 
Acteur secondaire : neant. 
Datede creation : le 31 /1 2/2004. 
Responsable : M. Dupont. 
Version : 1 .0. 

Sequencement 

Le cas demarre au point 3 de la description du cas « Emprunter une video ». 

Enchatnement nominal (le choix du film se fait par genres) 

1 . Le systeme demande au client quels sont ses criteres de recherche pour un film (les 
choix possibles sont : par titres ou par genres de film). 

2. Le client choisit une recherche par genres. 

3. Le systeme recherche les differents genres de film presents dans le distributeur. 

4. Le systeme affiche une liste des genres (les choix possibles sont action, aventure, come- 
die et drame). 

5. Le client choisit un genre de film. 

6. Le systeme affiche la liste de tous les films du genre choisi presents dans le distributeur. 

7. Le client selectionne un film. 

EnchaTnements alternatifs 

Al : Le client choisit une recherche par titres. 

L'enchamement demarre apres le point 1 de la sequence nominale : 

2. Le client choisit une recherche par titres. 

3. Le systeme affiche la liste de tous les films classes par ordre alphabetique des titres. 
La sequence nominale reprend au point 7. 

EnchaTnements d'exception 

El : Le client annule la recherche. 

L'enchamement peut demarrer aux points 2, 5 et 7 de la sequence nominale : 
Appel de I'exception E4 du cas « Emprunter une video ». 

Post-conditions 

Le systeme a memorise le film choisi par le client. 

Rubriques optionnelles 

Contraintes non fonctionnelles 

Contraintes liees a I'interface homme-machine 

Quand une liste de films s'affiche, le client peut trier la liste par titres ou par dates de sortie 
en salles. 

Le client peut se deplacer dans la liste et la parcourir de haut en bas et de bas en haut. 
Ne pas afficher plus de 10 films d la fois dans la liste. 
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Exercice 6 Relations d'extension entre cas d'utilisation, regroupement 
de cas d'utilisation en paquetages 



Modelisez a l'aide d'un diagramme de cas d'utilisation un systeme informatique de pilo- 
tage d'un robot a distance. 

Le fonctionnement du robot est decrit ci-apres. 

Un robot dispose d'une camera pour filmer son environnement. II peut avancer et reculer 
grace a un moteur electrique capable de tourner dans les deux sens et commandant la 
rotation des roues. II peut changer de direction car les roues sont directrices. II est pilote a 
distance : les images prises par la camera sont envoyees vers un poste de telepilotage. Ce 
dernier affiche l'environnement du robot sur un ecran. Le pilote visualise Fimage et utilise 
des commandes pour controler a distance les roues et le moteur du robot. La communica- 
tion entre le poste de pilotage et le robot se fait via des ondes radio. 



Solution 



Fir 
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Representation 
du systeme de 
telepilotage d'un 
robot par des 
paquetages. 



Le systeme informatique est compose de deux sous-systemes : 

• le sous-systeme du robot ; 

• le sous-systeme du poste de telepilotage. 

D'ou l'idee de faire deux diagrammes de cas d'utilisation - un par sous-systeme - et de 
placer chaque diagramme dans un paquetage. La figure 1.24 montre deux paquetages : un 
pour le sous-systeme du robot et un pour le sous-systeme du poste de pilotage. La relation 
de dependance entre les paquetages signifie que le systeme de pilotage utilise le robot. 





Commencons par modeliser le robot. Ses capteurs (camera, moteur et roues) sont a l'exte- 
rieur du systeme informatique et ils interagissent avec lui. lis correspondent a priori a la 
definition d'acteurs. Reprenons chaque capteur pour l'etudier en detail : 

• Le systeme doit demander la capture d'une image a la camera et realiser la capture. La 
camera est done un acteur associe a un cas d'utilisation appele « Capturer images » 
(figure 1.25). 

• Le sens de rotation du moteur peut etre commande. Le moteur est l'acteur ; il est associe 
a un cas appele « Commander le moteur ». 

• La direction des roues peut etre modifiee, d'ou la creation du cas d'utilisation « Com- 
mander la direction » relie a l'acteur Direction. 

Pour pouvoir envoyer les images au poste de pilotage et recevoir les commandes en retour, il 
faut un capteur supplementaire, emetteur/recepteur d'ondes radio. Le systeme informati- 
que ne va pas se charger d'envoyer et de recevoir des ondes radio - e'est le role des periphe- 
riques d'emission et de reception - mais il doit s'occuper du transcodage des images pour 
les envoyer via des ondes. Le systeme informatique doit-il realiser lui-meme ce transcodage 
ou bien les fonctions de transcodage sont-elles fournies avec les peripheriques ? Pour 
repondre a cette question, il faudrait realiser une etude de marche des emetteurs/recepteurs 
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radio. Cela depasse le cadre de cet ouvrage. Considerons que le systeme informatique inter- 
vient, ne serait-ce que pour appeler des fonctions de transcodage. Cela constitue un cas 
d'utilisation. Deux flots d'informations distincts doivent etre envoyes au poste de pilotage : 
des images et des commandes. Cette derniere remarque incite a creer deux cas d'utilisation : 
un pour emettre des images (« Envoyer les images ») et un pour recevoir les commandes 
(« Recevoir les commandes »). En outre, selon l'utilisation du robot, la transmission des 
images s'effectue plus ou moins vite : si les deplacements du robot sont rapides par exemple, 
la transmission doit l'etre aussi. Ces contraintes de realisation font partie des specifications 
techniques du systeme. Elles doivent figurer dans la description textuelle du cas d'utilisa- 
tion. Sur le diagramme de cas d'utilisation, il est possible de placer une relation d' extension 
entre les cas « Envoyer les images » et « Capturer images », en indiquant comme point 
d' extension a quel moment de la capture et a quelle frequence sont envoyees les images. 



Nom de l'acteur 


Role 


Camera 


Permet de capturer des images de Fenvironnement du robot. 


Direction 


Permet de diriger les roues du robot. 


Moteur 


Permet de faire avancer ou reculer le robot. 


Emetteur 


Permet d'envoyer des ondes radio. 


Recepteur 


Permet de recevoir des ondes radio. 



Figure 1 .25 

Diagramme de cas 
d'utilisation du 
robot. 




Moteur 



Direction 
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Interessons-nous a present au sous-systeme de pilotage. La figure 1.26 presente le dia- 
gramme de cas d'utilisation, qui se deduit sans probleme du diagramme precedent. 



Nom de l'acteur 


Role 


Pilote 


Represente un pilote qui agit sur les commandes a distance. 


Emetteur 


Permet d' envoyer des ondes radio. 


Recepteur 




Permet de recevoir des ondes radio. 



Figure 1 .26 

Diagramme de cas 
d'utilisation du 
systeme de pilotage. 



Sy steme de pilotage d'un robot 



Recepteur 
Condition : {des qu'une image 
complete a ete recue } 
Point d' extension : affichelmage 



Condition : {des qu'une commande r_^>. 
a ete manipulee par le pilote } 
Point d'extension : envoiCommande 



Emetteur 




Pilote 



Exercice 7 Relations entre acteurs, extensions conditionnelles entre cas 
d'utilisation 



Modelisez a l'aide d'un diagramme de cas d'utilisation une mediatheque dont le fonction- 
nement est decrit ci-apres. 

Une petite mediatheque n'a qu'une seule employee qui assume toutes les taches : 

• la gestion des oeuvres de la mediatheque ; 

• la gestion des adherents. 

Le pret d'un exemplaire d'une ceuvre donnee est limite a trois semaines. Si l'exemplaire 
n'est pas rapporte dans ce delai, cela genere un contentieux. Si l'exemplaire n'est toujours 
pas rendu au bout d'un an, une procedure judiciaire est declenchee. 

L'acces au systeme informatique est protege par un mot de passe. 
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Solution 



La mediatheque n'emploie qu'une employee. Neanmoins, un acteur est determine par le 
role qu'il joue vis-a-vis du systeme a modeliser. Ici, 1' employee a deux roles essentiels : 



• le role de bibliothecaire qui gere les oeuvres ainsi que les adherents ; 

• le role de gestionnaire des contentieux ayant les connaissances juridiques suffisantes pour 
declencher des procedures judiciaires. 

Ces roles sont modelises par deux acteurs : Bibliothecaire et Gestionnaire des contentieux. 
Un gestionnaire de contentieux est un bibliothecaire avec pouvoir. Les acteurs correspon- 
dants sont relies par une relation de generalisation (figure 1.27). Ainsi, l'acteur Gestionnaire 
des contentieux peut utiliser les cas associes a l'acteur Bibliothecaire. A contrario, l'acteur 
Bibliothecaire ne peut pas utiliser les cas relatifs a la gestion des contentieux. 

Jusqu'a present la mediatheque fonctionne avec une seule employee. Si, a l'avenir, plusieurs 
employes devenaient necessaires, le systeme informatique pourrait fonctionner avec deux 
groupes d'utilisateurs : un premier groupe dont le role serait limite a celui des bibliothe- 
caires et un deuxieme groupe susceptible de gerer les contentieux en plus d'avoir un role de 
bibliothecaire. L'authentification du groupe auquel appartient un utilisateur du systeme 
doit etre controlee par un mot de passe. La gestion des mots de passe requiert la presence 
d'un administrateur du systeme. Pour UML, peu importe si cette personne fait partie ou 
non du groupe des bibliothecaires ou des gestionnaires de contentieux. Comme un nouveau 
role apparait dans le systeme, cela justifie la definition d'un acteur supplemental : Admi- 
nistrateur. Tous les cas d'utilisation lies aux acteurs incluent la procedure d'authentification 
materialisee par le cas « S'authentifier ». 

Dans le diagramme, la gestion des adherents et la gestion des emprunts sont separees : 
« Gerer les adherents » consiste a ajouter, a supprimer ou a modifier l'enregistrement d'un 
adherent dans la mediatheque, tandis que « Gerer les emprunts » consiste a preter des exem- 
plaires aux adherents deja inscrits. 

La gestion des contentieux a deux degres d'alerte : 

• Un exemplaire n'a pas ete rendu au bout de trois semaines. 

• Un exemplaire n'a toujours pas ete rapporte au bout d'un an. 

Cela correspond a deux fonctionnalites distinctes puisque, dans le deuxieme cas seulement, 
il faut declencher une procedure judiciaire. Nous representons cela par deux cas d'utilisa- 
tion : « Gerer les contentieux » et « Declencher une procedure judiciaire ». Ces deux cas sont 
lies par une relation d'extension soumise a la condition « si le retard depasse un an ». 



Nom de l'acteur 


Role 


Bibliothecaire 


Represente un bibliothecaire. 11 gere les oeuvres, les adherents et les 
emprunts. 


Gestionnaire des 
contentieux 


Represente un bibliothecaire qui peut gerer les contentieux. 


Administrateur 


Represente un gestionnaire des droits d'acces au systeme. 
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Figure 1 .27 

Diagramme de cas 
d'utilisation d'une 
mediatheque. 



BibliothecaireN 



Gestionnaire des 
contentieux 



Une mediatheque 




Points d' extension : 
procedureJudiciaire : {pas a 
chaque fois que le gestionnaire 
utilise le cas mais 
une fois par mois } 

Condition : {si plus d'un an de retard) 



Point d'extension : procedureJudiciaire 



« etend » 



Declencher une 
procedure judiciaire 



Administrateur 



Exercice 8 Identification des acteurs, recensement des cas d'utilisation 
internes et relation de generalisation entre cas 



Modelisez a l'aide d'un diagramme de cas d'utilisation le systeme informatique qui gere la 
distribution d'essence dans une station-service. Le fonctionnement de la distribution de 
l'essence est decrit ci-apres. 

Avant de pouvoir etre utilisee par un client, la pompe doit etre armee par le pompiste. La 
pompe est ainsi appretee, mais ce n'est que lorsque le client appuie sur la gachette du pis- 
tolet de distribution que l'essence est pompee. Si le pistolet est dans son etui de rangement 
et si la gachette est pressee, l'essence n'est pas pompee. La distribution de l'essence a un 
client est terminee quand celui-ci remet le pistolet dans son etui. La mesure de l'essence 
distribute se fait par un debitmetre. 

Quatre types de carburants sont proposes : diesel, sans plomb avec un indice d'octane de 
98, sans plomb avec un indice d'octane de 95, et plombe. 

Le paiement peut s'effectuer en especes, par cheque ou par carte bancaire. En fin de jour- 
nee, les transactions sont archivees. 

Le niveau des cuves ne doit pas descendre en dessous de 5 % de la capacite maximale. 
Sinon les pompes ne peuvent plus etre armees. 



Diagramme de cas d'utilisation 29 



Solution 



Pour un systeme complexe, il vaut mieux se concentrer sur les fonctions essentielles puis 
passer aux cas moins importants. 



Identification des principaux acteurs et recensement des cas d'utilisation 
essentiels 

L'acteur principal est evidemment le client. II utilise le systeme pour obtenir de Fessence. Il 
est associe au cas d'utilisation « Se servir ». Rappel : dans un diagramme de cas d'utilisation, 
on ne detaille pas la sequence des operations. Par exemple, le type d'essence choisi sera pris 
en compte quand on decrira le cas. 

Imaginons le fonctionnement de la pompe : l'essence ne peut etre distribute que si la 
pompe est armee ; le client prend un pistolet ; sur le pupitre du pompiste est indique le type 
d'essence choisi ; le pompiste arme la pompe en appuyant sur un bouton de son pupitre, ce 
qui initialise la pompe. 

Ainsi, le cas « Se servir » doit inclure l'armement de la pompe. Deux solutions sont possi- 
bles : 

• La premiere utilise un cas unique (Se servir), et deux acteurs (Client et Pompiste), 
comme le montre la figure 1.28. 



Figure 1 .28 

Se servir de 
l'essence : solution 
avec un cas unique. 



Se Servir 



Client 



Pompiste 



La deuxieme solution met en ceuvre deux cas : « Se servir » et « Armer pompe » 
(figure 1.29). 



Figure 1 .29 

Se servir de 
l'essence : solution 
avec deux cas. 




Client 



Pompiste 



L'armement de la pompe est indispensable, sinon l'essence ne peut etre distribute, d'ou la 
relation d'inclusion entre les cas « Se servir » et « Armer pompe ». L'armement de la pompe 
se fait en une seule action pour le pompiste : celle d'armer la pompe en appuyant sur un 
bouton. La description de l'armement se resume done a une sequence tres sommaire 
d' actions. Faut-il alors representor cela par un cas d'utilisation ? L'argument qui fait pencher 
pour le maintien du cas « Armer pompe » est que l'armement est une operation bien isolee 
des autres fonctions : il s'agit d'initialiser la pompe et done de piloter des peripheriques 
(mecaniques, electroniques. . .). Vu sous cet angle, l'armement est suffisamment complexe 
et bien isole des autres fonctions pour en faire un cas (figure 1.31). 

Le pompiste est un acteur secondaire du cas « Armer pompe » (e'est un cas interne pour 
lequel le pompiste est consulte). L'armement de la pompe n'est possible que si le niveau de 
la cuve est suffisant. Un detecteur de niveau (peripherique externe au systeme informati- 
que) est necessaire. Ce peripherique est represente par l'acteur « Capteur niveau cuve pour 
armement ». II est secondaire car l'information sur le niveau de la cuve ne lui est pas desti- 
nee. Si le niveau est trop bas, e'est le pompiste qui doit en etre informe. II saura ainsi ce qui 
empeche l'armement de la pompe. La verification du niveau de la cuve est importante pour 
le systeme. De plus, cette operation constitue une transaction bien isolee des autres fonc- 
tions (il s'agit de controler un peripherique materiel). C'est la raison pour laquelle on 
decide de creer un cas « Verifier niveau cuve pour armement ». Pour transmettre le niveau 
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de la cuve au pompiste, il faut relier l'acteur Pompiste au cas « Verifier niveau cuve pour 
armement ». Le pompiste est informe que le niveau est trop bas, mais la verification doit 
etre automatique pour que les pompes soient eventuellement bloquees. Une relation 
d'inclusion intervient done entre les cas « Armer pompe » et « Verifier niveau cuve pour 
armement » (figure 1.31). 

Recensement des cas de moindres importances 

Apres avoir trouve les principaux cas, il est temps de se consacrer a ceux de moindre impor- 
tance. II ne faut pas oublier de couvrir tous les besoins et ne pas hesiter a introduire des cas 
auxquels le maitre d'ouvrage n'a pas pense. II validera ou pas le modele a posteriori. 

L'enonce n'aborde pas le probleme du remplissage des cuves d'essence. Cette operation est 
realisee par une entreprise tierce de livraison d'essence. Elle doit cependant etre consignee 
dans le systeme informatique de la station-service. Une solution consiste a alerter le pom- 
piste des que le niveau des cuves descend au-dessous d'un certain seuil. Ce deuxieme seuil, 
appele « seuil de remplissage des cuves », doit etre superieur au seuil des 5 % de l'enonce 
(celui qui empeche les pompes d'etre armees). Quand il est atteint, le pompiste previent 
l'entreprise de livraison d'essence de sorte a eviter de tomber au seuil des 5 %. Si la station- 
service est sur une autoroute, la livraison d'essence doit etre garantie 24 heures sur 24. II faut 
peut-etre contacter la societe de livraison automatiquement - sans passer par l'interme- 
diaire du pompiste - des que le niveau devient trop bas. Le capteur du niveau de remplissage 
est represente par un acteur appele « Capteur niveau cuve pour remplissage » (figure 1.31). 
II est associe au cas « Verifier niveau cuve pour remplissage », lui-meme associe a l'acteur 
Pompiste. 

Abordons a present le probleme du paiement. De concert avec le maitre d'ouvrage, le maitre 
d'oeuvre imagine un fonctionnement possible du systeme : des que le client raccroche le pis- 
tolet, le montant a payer est calcule ; il s'affiche sur le pupitre du pompiste ; le client qui 
vient payer indique son mode de paiement (especes, cheque ou carte bancaire) ; le pompiste 
selectionne le mode de paiement choisi. A partir de la, les cas divergent : 

• Pour un paiement en especes, le pompiste encaisse le montant demande, puis valide la 
transaction, qui est memorisee dans le systeme informatique (le montant, la date de la 
transaction et le mode de paiement sont conserves). 

• Si le paiement se fait par cheque, ce dernier est rempli automatiquement, puis le pom- 
piste l'encaisse. La transaction est memorisee dans le systeme informatique (en plus de la 
date, du montant et du mode paiement, sont conserves les references d'une piece d'iden- 
tite ou le numero d'immatriculation du vehicule). 

• Pour un paiement par carte bancaire, la banque de la station-service realise une transac- 
tion avec la banque du client. Les seules informations a conserver dans le systeme infor- 
matique de la station-service sont le montant, la date de la transaction et le mode de 
paiement. 

Comment representer cela dans un diagramme de cas d'utilisation ? Une premiere solution 
(presentee a la figure 1.31) consiste a creer un cas general appele « Payer », et trois cas parti- 
culiers relies par une relation de specialisation au cas « Payer ». Chacun des trois cas represente 
un mode de paiement. 

Une autre solution (presentee a la figure 1.30) repose sur un cas, « Payer », qui se deroule 
jusqu'au choix du mode de paiement, puis, selon le type de paiement, un des trois modes 
est active (« Payer en especes », « Payer par cheque » ou « Payer par carte bancaire »). Ces 
trois cas sont typiquement des extensions du cas « Payer », ou l'extension est soumise a 
condition. 



Diagramme de cas d'utilisation 



Figure 1 .30 

Utilisation 
de relations 
d'extension 
pour modeliser 
le paiement. 



Condition : { si le client choisit de payer 
par carte bancaire} 

Point d'extension : paiementParCarteBancaire 



Condition : { si le client choisit de 
payer par cheque} 

Point d'extension : paiementParCheque 




Condition : {si le client 
choisit de payer en espece 
Point d'extension : 
paiementEnEspece 



Ces deux solutions sont possibles. II est difficile de dire laquelle est la meilleure. La suite de 
l'exercice se fonde arbitrairement sur la representation avec des relations de generalisation 
(figure 1.31). Le modelisateur se retrouve regulierement face a ce dilemme. La reponse est 
souvent la meme : peu importe la facon de modeliser un systeme du moment que le modele 
est correct - un modele est correct s'il montre une solution qui satisfait le maitre d'ouvrage 
ainsi que les futurs utilisateurs du systeme. 

Aboutir a une modelisation correcte 

II faut prendre le temps d'elaborer le diagramme de cas d'utilisation, bien qu'il soit generale- 
ment simple a batir, afin d'eviter les a priori qui peuvent conduire a une modelisation erronee. 

A la relecture du fonctionnement du paiement tel qu'il est decrit precedemment, le pom- 
piste devient l'acteur principal du cas de paiement. C'est un peu surprenant car on pourrait 
croire au premier abord qu'il s'agit du client. Or, la seule fois ou le client intervient directe- 
ment sur le systeme informatique de la station-service est quand il saisit son numero de 
carte bancaire. Toutes les autres situations necessite l'intervention du pompiste. Attardons- 
nous un instant encore sur le paiement par carte bancaire. II faut de toute evidence faire 
figurer un acteur supplemental qui represente la banque, car elle interagit avec le systeme 
sans en faire partie. C'est un acteur secondaire qui est sollicite uniquement pour confirmer 
le bon deroulement de la transaction. Quel est le role de cet acteur ? Le plus souvent, les 
solutions de paiement par carte bancaire sont disponibles cles en main sur le marche. Elles 
incluent un lecteur de cartes ainsi qu'un logiciel pour le piloter. Le maitre d'ceuvre doit pro- 
poser plusieurs solutions presentes sur le marche au maitre d'ouvrage, et eventuellement 
une solution proprietaire si aucune solution du marche ne lui convient. Le maitre d'ouvrage 
decidera. Dans le cadre de cet exercice, a defaut de pouvoir dialoguer avec un maitre 
d'ouvrage, nous choisissons l'achat d'une solution cles en main pour le paiement par carte 
bancaire. Dans ce cas, le client, lorsqu'il saisit le code de sa carte, n'interagit plus directe- 
ment avec le systeme informatique de la station-service. Ainsi, quel que soit le mode de 
paiement, tout passe par l'intermediaire du pompiste. Le client n'est done pas un acteur du 
systeme. 

Le calcul automatique du montant a payer peut se faire des que le client raccroche le pistolet 
(ce qui intervient a la fin du cas « Se servir »). Pour indiquer le moment ou le montant est 
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calcule, on peut ajouter une relation d'extension entre les cas « Se servir » et « Payer », avec 
un point d'extension qui precise le moment ou le calcul du montant intervient, comme le 
montre la figure 1.31. Le paiement peut aussi intervenir avant de se servir. Dans ce cas, il est 
possible d'ajouter un deuxieme point d'extension (voir la figure 6.17 du chapitre 6). 

Moderation des concepts abstraits 

Parfois, le langage UML peut paraitre limite. II faut alors trouver, parmi les elements du lan- 
gage, celui qui convient le mieux a une situation donnee. 

Un dernier besoin n'est pas decrit par le diagramme de cas d'utilisation : c'est l'archivage 
en fin de journee des transactions. Faut-il prendre en compte ce cas et, si oui, quel acteur 
l'utilise ? Un cas d'utilisation est declenche par un evenement. Les evenements peuvent etre 
classes en trois categories : 

• Les evenements externes. lis sont declenches par des acteurs. 

• Les evenements temporels. lis resultent de l'atteinte d'un moment dans le temps. 

• Les evenements d'etats. lis se produisent quand quelque chose dans le systeme necessite 
un traitement. 

Ici, il s'agit d'un evenement temporel. II est difficile de definir un acteur qui declencherait 
cet evenement. Comment le temps peut-il interagir avec un systeme ? Cela dit, l'archivage 
quotidien est une fonctionnalite essentielle. II faut la faire figurer dans la modelisation du 
systeme. A quelle etape de la modelisation doit-on prendre en compte cette fonctionnalite ? 
Comme nous en sommes a produire le premier modele du systeme et que cette fonctionna- 
lite est importante, nous choisissons, pour ne pas l'oublier, d'en faire un cas d'utilisation. 
Pour declencher ce cas, nous introduisons un acteur appele Timer qui, une fois par jour, 
declenche un evenement temporel. Timer est un acteur, il est done en dehors du systeme. 
Cela signifie que l'heure est donnee par une horloge externe a notre systeme informatique 
(par exemple, l'horloge du systeme d'exploitation du systeme informatique). 

La prise en compte des evenements d'etats est plus delicate puisque, par definition, ils se 
produisent a l'interieur d'un systeme. Ils ne peuvent done pas etre declenches par un acteur, 
qui est forcement en dehors du systeme. II est toutefois possible qu'un evenement d'etat 
active un cas d'utilisation a condition que ce cas soit interne au systeme. Une facon de 
representer un cas de ce type consiste a le relier a d'autres cas via des relations d'extension et 
a faire figurer comme condition d'extension l'evenement d'etat. C'est cette solution qui a 
ete adoptee entre les cas « Se servir » et « Payer », en considerant ce dernier comme un cas 
interne vis-a-vis du cas « Se servir ». 



Nom de l'acteur 


Role 


Client 


Acteur principal du cas d'utilisation « Se servir ». Represente le client 
qui se sert de l'essence. 


Pompiste 


Acteur principal des cas « Payer » et « Verifier niveau cuve pour 
remplissage ». Acteur secondaire pour le cas « Armer pompe ». 


Capteur niveau cuve 
pour armement 


Acteur secondaire du cas « Verifier niveau cuve pour armement ». 


Capteur niveau cuve 
pour remplissage 


Acteur secondaire du cas « Verifier niveau cuve pour remplissage ». 


Timer 


Acteur secondaire du cas « Archiver les transactions ». 


Banque 


Acteur secondaire du cas « Payer par carte bancaire ». 



Diagramme de cas d'utilisation 



Figure 1 .31 

Diagramme de cas 
d'utilisation d'une 
station-service. 



Capteur niveau cuve 
pour armement 



Capteur niveau cuve 
pour remplissage 



Client 



Station-Service 



Verifier niveau cuve A 
pour remplissage J 



Condition : {si le client 
a pris de l'essence avant 
de raccrocher le pistolet) 



Banque 





Pompiste 



Payer par carte 
bancaire 



Tous les soirs a minuit 




Timer 
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□ Exemple de diagramme de classes 



Les classeurs decrivent les caracteristiques structurelles et comportementales de certains 
elements du modele UML. Les classes, les interfaces, les associations, les cas d'utilisation, les 
collaborations, les acteurs, les types primitifs, les composants, les signaux sont des speciali- 
sations possibles de classeurs. 

Le diagramme de classes presente un ensemble de classeurs. II decrit les classes et leurs 
relations, comme le montre Fexemple suivant. II peut egalement decrire les regroupements 
de classes en paquetages, les interfaces et les objets, les classes qui participent a une collabo- 
ration ou qui realisent un cas d'utilisation, etc. 



Exemple 



Figure 2.1 

Exemple de 
diagramme 
de classes. 



La figure 2.1 modelise une entreprise d I'aide de cinq classes : Entreprise, Service, Bureau, 
Employe et Siege. Les classes possedent eventuellement des attributs (la classe Service est 
caracterisee par un nom, un employe se caracterise par un nom et un identifiant). Elles 
contiennent aussi des operations (demandeConges pour la classe Employe). Les classes sont 
reliees entre elles par des associations symbolisees par des traits. Plusieurs types d'associa- 
tions existent, qui se represented differemment (par des losanges, des fleches...). 



Une agregation 



egation - _ _ _ Entreprise 



I..* 



1..* 



Service 

Une contrainteh '— 0| nom : String 
entre relations 

'- - I subset } — 5 
membre 1 



Op eration"^ 



utilise ► 



chef 



Employe 



nom : String 
identifiant : Number 



demandeCongesO :bool 





1..* 


Bureau 


L 


\ 


Siege 



Pour creer un diagramme de classes, vous avez besoin d'abord de definir les classes et leurs 
responsabilites, les paquetages ainsi que les relations (association, composition, agregation, 
heritage, dependance. . . ) possibles entre ces elements. D'autres elements peuvent egalement 
apparaitre dans le diagramme de classes, comme les objets et les interfaces. 

Nous presenterons, dans ce chapitre, les elements indispensables pour bien reussir la mode- 
lisation du diagramme de classes. Commencons par decrire la genese des classes. 



0 De I'objet d la classe 

Beaucoup d'objets naturels ou informatiques se ressemblent tant au niveau de leur descrip- 
tion que de leur comportement. Afin de limiter la complexity de la modelisation, vous pou- 
vez regrouper les objets ayant les memes caracteristiques en classes. Ainsi, une classe decrit 
les etats (ou attributs) et le comportement a haut niveau d'abstraction d'objets similaires. 

De cette facon, vous pouvez definir la classe comme le regroupement des donnees et des 
traitements applicables aux objets quelle represente, comme le montre la figure 2.2. Dans 
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Fapproche objet, il faut, avant tout, pouvoir identifier les objets, les differencier des autres 
avant de les definir. L'identite associee a une classe est essentielle car elle conditionne la per- 
ception des structures et des comportements des objets quelle represents 



EXEMPLE 



La figure 2.2 modelise la situation suivante : Jean est un homme celibataire age de 40 ans et 
Anne est une femme mariee. 



Figure 2.2 

Representation UML 
de la classe 
Personne. 



Personne 



prenom : String 
dateNaissance : Date 
sexe : {'M','F } 



calculAgeO : Integer 
renvoyerNomQ : String 



Le nom de la classe doit etre significatif et 
complet. II commence par une majuscule. S'il est 
compose de plusieurs mots, la premiere lettre de 
chaque mot doit etre une majuscule. Personne 



Liste des attributsde la classe avec les (X, 
modificateurs d'acces eventuels. Certains attributs 
n'apparaissent pas directement, ils seront deduits 
a partir des relations entre classes. 



Liste des methodes de la classe. Quand la ^ 
methode accepte des parametres alors ces 
parametres et leurs types sont ajoutes entre les 
parentheses. 



Dans cet exemple, on regroupe les similarites entre les deux objets Jean et Anne dans une 
classe Personne. Les informations qui apparaissent dans l'exemple sont le prenom, le sexe et 
la situation matrimoniale. De ce fait, la classe Personne est munie des attributs suivants : 
prenom, sexe et situation matrimoniale. L'age est une donnee qui change. On le calcule en 
faisant la difference entre la date courante et la date de naissance. On parle dans ce cas 
d'attributs derives. Cette derniere analyse permet de completer la description de la classe en 
ajoutant l'attribut date de naissance et une operation permettant le calcul de l'age. 

En UML, la classe Personne est representee graphiquement par un rectangle divise en plusieurs 
compartiments. Le premier compartiment indique le nom de la classe, le deuxieme ses attri- 
buts, le troisieme ses methodes. En fonction de l'etat de la modelisation et des elements a 
mettre en valeur, d'autres compartiments, comme les compartiments de responsabilites et 
d'exceptions, peuvent etre ajoutes a la description de la classe. 

Definition 

Une classe est une description d'un ensemble d'objets ayant une semantique, des attributs, 
des methodes et des relations en commun. Un objet est une instance d'une classe. 



Remarque 

Dans les langages de programmation objet, on confond souvent la notion d'instance et la 
notion d'objet alors que la premiere est plus generale que la seconde. Un objet est une ins- 
tance d'une classe. Mais une instance peut etre une instance de plusieurs autres elements 
du langage UML. Par exemple, un lien est une instance d'une association. 



Un objet d'une classe doit avoir des valeurs uniques pour tous les attributs definis dans la 
classe et doit pouvoir executer (sans exception) toutes les methodes de la classe. 
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2.1 Classe et methode abstraites 



Dans votre environnement quotidien, vous faites abstraction d'une quantite de details qui 
permettent d'avoir une vision globale et generalisante du monde. Cette notion d'abstrac- 
tion se retrouve, au sein de l'approche objet, dans les classes et les methodes abstraites. 
Imaginez une classe modelisant une figure geometrique. Toutes les figures geometriques 
doivent pouvoir etre dessinees. Ajoutez a cette classe une operation qui permet de dessiner 
une figure. A ce stade de la modelisation, vous etes dans l'incapacite de definir l'implemen- 
tation de cette operation. On l'appelle « methode abstraite ». 

Definition 

Une methode est dite abstraite lorsqu'on connaft son entete mais pas la maniere dont elle 
peut etre realisee. Une classe est dite abstraite lorsqu'elle definit au moins une methode 
abstraite ou lorsqu'une classe parent contient une methode abstraite non encore realisee. 



EXEMPLE Chaque element graphique du langage UML est represents par une figure geometrique. 

Les caracteristiques communes de ces figures geometriques sont le type de trait utilise pour les 
dessiner et la possibility de les dessiner. 

II est evident que si nous ne connaissons pas la forme exacte de la figure a dessiner nous ne 
pouvons pas le faire. On dira de ce fait que la methode dessiner est abstraite dans la classe 
FigureGeometrique et la classe FigureGeometrique est done elle-meme abstraite. Cependant, 
si on definit un rectangle comme particularisation de la figure geometrique alors le rectan- 
gle pourra etre dessine et la methode dessiner fournit ainsi un corps a l'operation dessiner 
qui sera dite concrete. Une classe abstraite contient au moins une methode abstraite. La 
figure 2.3 donne un exemple d'une classe abstraite contenant une methode abstraite et les 
consequences de cette propriete sur les classes derivees. En particulier, une classe qui derive 
d'une classe abstraite doit implementer toutes les methodes abstraites sinon elle reste aussi 
abstraite. 



Implementation de 
l'operation dessiner 



Cette classe reste abstraite 
car elle n'implemente pas 
la methode dessiner 



2.2 NOM DE LA CLASSE 



La modelisation d'une classe passe par plusieurs etapes auxquelles participent eventuelle- 
ment plusieurs intervenants. Par exemple, une classe peut etre extraite des cas d'utilisation 
par un analyste programmeur, et apres analyse et factorisation operees par un ingenieur de 
developpement, etre mise dans un paquetage predefini et considered comme valide. Pour 
distinguer ces etapes de modelisation, vous devez ajouter au nom de la classe toutes les 
informations pertinentes. 



rigure ^.o 

Exemple de classe 
abstraite. 



FigureGeometrique) abstract} 




Rectangle 




<3 




typeTrait : Trait 


dessiner() 


dessiner() {abstract} 


FigurePleinej abstract} . ^ 
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Les informations les plus souvent utilisees sont le nom de la classe, les paquetages qui la 
contiennent, le stereotype eventuel de la classe, l'auteur de la modelisation, la date, le statut 
de la classe (elle est validee ou pas). Par defaut, une classe est consideree comme concrete. 
Sinon, ajoutez le mot-cle abstract pour indiquer quelle est abstraite. 



Specification 



La syntaxe de base de la declaration d'un nom d'une classe est la suivante 
[« stereotype »] 

[<NomDuPackage1> : : <NomDuPaquetage N>::] 
<NomDeLaClasse>[ { [abstract] , [auteur] , [etat] ,...}] 



Figure 2.4 

Quelques exemples 
de noms de classe. 



NomSimple 



nomPackage::NomSimple 



Personne 



java::util:: Vector 



FigureGeometrique 
{ abstract, 
auteur : osmani 
etat : validee! 



« Controleur s 
LeGardien 



Remarque 

Le nom de la classe doit evoquer le concept decrit par la classe. II commence par une 
majuscule. Quand le nom est compose, chaque mot commence par une majuscule et les 
espaces blancs sont elimines. 

En UML 2, les guillemets (comme dans I'exemple de « controleur » servent, a la fois, a indi- 
quer les stereotypes et les mots-cles du langage. Dans les versions precedentes d'UML, ils 
ne servent qu'a designer les stereotypes. 



2.3 Encapsulation 



Un principe de conception largement utilise (meme au-dela de l'approche objet) consiste a 
proteger le cceur d'un systeme des acces intempestifs venant de l'exterieur. C'est le principe 
du coffre-fort : seuls les detenteurs d'une clef peuvent l'ouvrir. Transpose a la modelisation 
objet, ce principe s'appelle l'encapsulation. II permet de defmir les droits d'acces aux 
proprietes d'un classeur. UML deflnit quatre niveaux d'encapsulation d'une propriete d'une 
classe. 

Une propriete peut etre visible partout. Dans ce cas, elle est dite « publique ». Si elle n'est 
visible qu'a l'interieur d'une classe, elle est dite « privee ». En utilisant le principe de 
l'heritage, les descendants d'une classe peuvent avoir un acces privilegie aux proprietes des 
classes parentes. Une classe parent qui souhaite autoriser Faeces a une de ses proprietes a 
ses seuls descendants doit defmir cette propriete comme « protegee ». Lors de la modelisa- 
tion d'applications complexes, les classes sont regroupees dans des paquetages dedies a des 
domaines ou activites particulieres. Le langage Java, par exemple, propose un paquetage 
dedie aux entrees/sorties (java.io), un paquetage contenant les utilitaires {java.util), etc. La 
visibilite par defaut d'une classe et de ses proprietes se limite au paquetage dans lequel elle 
est defmie. 
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Notation 




Les modificateurs d'acces ou de visibility associes aux classes ou d leurs proprietes sont notes 
comme suit : 

• Le mot-cle public ou le caractere +. Propriete ou classe visible partout. 

• Aucun caractere, ni mot-cle. Propriete ou classe visible uniquement dans le paquetage 
ou la classe est definie. 

• Le mot-cle protected ou le caractere #. Propriete ou classe visible dans la classe et par 
tous ses descendants. 

• Le mot-cle private ou le caractere -. Propriete ou classe visible uniquement dans la classe. 

Par ailleurs, le langage UML 2 donne la possibility d'utiliser n'importe quel langage de 
programmation pour la specification de la visibilite des classeurs et de leurs proprietes. II 
suffit pour cela de preciser le langage utilise. 



Le paquetage Paquetagel utilise le paquetage Paquetage2. La classe Classel definit quatre 
attributs avec des visibilites differentes (figure 2.5). L'attribut prive attributl n'est accessible 
que dans la classe Classel . L'attribut attribut2 est « public » dans le paquetage, accessible a 
partir des classes Classel, Classe2 et Classed. L'attribut attribut3 est accessible a partir des 
quatre classes alors que l'attribut attribut4 n'est visible que dans les classes Classel et 
Classe2. 



Figure 2.5 

Visibilite 
des proprietes 
d'une classe. 



Paquetagel 



+ Classel 




-attributl 




attribut2 




+attribut3 




#attribut4 




+ Classe3 


accessibles 


attribut2 


attribut3 



+ Classe2 



accessibles 
attribut2 
attribut3 
attribut4 



< 



« import » 



Paquetage2 



+ Classe4 



accessibles 
attribut3 



2.4 Attributs de la classe 



Les attributs definissent les informations qu'une classe ou un objet doivent connaitre. lis 
representent les donnees encapsulees dans les objets de cette classe. Chacune de ces infor- 
mations est definie par un nom, un type de donnees et une visibilite. Le nom de l'attribut 
doit etre unique dans la classe. 

En UML, les attributs correspondent a des instances de classes deja predefmies. Pour des 
raisons de programmation, ce principe n'est pas toujours respecte par les langages de pro- 
grammation objet, comme en temoigne l'existence de types de base (int, float,...) dans les 
langages Java et C++. 



EXEMPLE La classe Hotel possede un nom et un proprietaire. Un hotel contient entre une et deux cents 

chambres. Le proprietaire de I'hotel n'est pas visible d partir des autres classes. Par ailleurs, 
I'hotel respecte les textes de lois communs a tous les hotels. 
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Pour pouvoir modeliser la classe Hotel, vous avez besoin de connaitre les classes String, 
Chambre, Personne et TexteDeLoi. Vous avez egalement besoin de savoir modeliser la multi- 
plicite (entre une et deux cents chambres) et la possibilite d'associer une propriete a la 
classe, et non a l'instance de la classe (texte de loi). 



Figure 2.6 

Classe Hotel 
mettant en evidence 
les modificateurs 
d'acces, la multipli- 
city et les attribute 
de classes. 



Hotel 



+ chambres : Chambre [1.. 200] 
+ nom : String 
-proprietaire : Personne 
+ texte : TexteDeLoi 



Description des attributs en mettant en evidence la 
visibilite et la multiplicity, Dans le cas ou la multiplicite est 
representee par plusieurs intervalles, ils sont ordonnes par 
ordre croissant. Quand les intervalles sont continus,ils 
doivent etre regroupes. 
Exemple : [5. .6] doit etre prefere a "5,6 ". 



Le texte de loi qui regit la profession n'est pas propre [^^i 
a un hotel. Elle existe en un seul exemplaire, partagee par 
toutes les instances d'hotel. II s'agit d'un attribut de classe 
(souligne). 



Notation 



Un attribut peut etre initialise et sa visibilite est definie lors de sa declaration. La syntaxe de 
la declaration d'un attribut est la suivante : 

<modif icateur d'acces> [ / ] <NomAttribut> : 
<NomClasse>[ 1 [ 'multiplicite' ]' ] [ = valeur(s) initiale(s)] 



Les attributs de classes 

Par defaut, les valeurs des attributs definis dans une classe different d'un objet a un autre. 
Parfois, il est necessaire de definir un attribut qui garde une valeur unique et partagee par 
toutes les instances de la classe. C'est par exemple le cas de la valeur de la variable PI=3,14 
definie dans la classe Math du langage Java. Quel que soit l'objet de cette classe, la valeur de 
PI reste la meme. De plus, cette valeur est accessible meme s'il n'existe aucun objet de la 
classe Math. On dit alors que PI est un attribut de la classe Math, et non un attribut de ses 
instances. Les instances ont acces a cet attribut, mais n'en possedent pas une copie. 

Graphiquement, un attribut de classe est souligne, comme le montre Fexemple de TexteDe- 
Loi de la figure 2.6. En Java, comme en C++, par exemple, un attribut de classe s'accompa- 
gne du mot-cle static. 



Les attributs derives 

Les attributs derives, symbolises par l'ajout d'un slash (/) devant leur nom, peuvent etre 
calcules a partir d'autres attributs et des formules de calcul. Lors de la conception, un attri- 
but derive peut etre utilise comme marqueur jusqu'a ce que vous puissiez determiner les 
regies a lui appliquer. 



EXEMPLE La plupart des calculs concernant la pension de retraite sont bases sur l'age. L'age est vu 

comme un attribut. Pourtant, lors de la modelisation de la classe Personne, c'est la date de 
naissance qui est determinante, et non l'age, car celui-ci change en fonction de la date du 
jour. De ce fait, on dit que I'attribut age est un attribut derive : il est utilise comme un vrai 
attribut mais calcule par une methode. II est note /age : integer. 
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2.5 Methodes et operations 



Le comportement d'un objet est modelise par un ensemble de methodes. Chaque methode 
correspond a une implementation bien precise d'un comportement. 

En general, lors de la conception des classes, on commence par donner les en-tetes des 
methodes sans preciser la maniere de les implementer. Cependant, avant toute instanciation 
d'une classe, il est necessaire de donner une implementation possible de ses methodes. Evi- 
demment, pour chaque en-tete, plusieurs implementations sont possibles. 

UML distingue la specification d'une methode, qui correspond a la definition de son en- 
tete, de son implementation. La specification est appelee « operation » et l'implementation 
est appelee « methode ». Vous pouvez done associer plusieurs methodes a une operation, 
comme le montre l'exemple suivant : 



EXEMPLE Soit la factorielle de n (n!), une fonction definie de facon inductive pour tout entier positif n 

par : 0! = 1 et n! = n * (n - 1)!. On dit que : + fact (n : integer) : integer est une operation et 
que 

+fact(n:integer) : integer 
{ if (n==0 || n==1 ) renvoyer (1) ; 
renvoyer (n * fact(n-1) ; *= i ; 

} 

et 

+fact(n:integer) :integer 
{ int resultat = 1 ; 

pour (int i = n ; i>0 ; i--) resultat*=i ; 

renvoyer resultat ; 

} 

sont deux methodes possibles implementant I'operation fact( ). 

Dans une classe, une operation (meme nom et memes types de parametres) doit etre uni- 
que. Quand le nom d'une operation apparait plusieurs fois avec des parametres differents, 
on dit que I'operation (et/ou la methode) est surcharges. En revanche, il est impossible que 
deux operations ne se distinguent que par la valeur retournee. 

Specification 

La specification d'une operation contient les types des parametres et le type de la valeur 
de retour. UML 2 ne prevoit pas de type de la valeur de retour d'une operation. Mais I'uti- 
lite de ce parametre nous conduit a garder la syntaxe d'UML 1 .5. 
La syntaxe de la declaration est la suivante : 

<modif icateur d 1 acces><nomDeLaMethode ( [parametres] )> : 
[<valeurRenvoyee>] [ {propriete} ] 

La syntaxe de la liste des parametres est la suivante : 

<NomClasse> nomVariable , <NomClasse> nomVariable, <NomClasse> 
nomVariable,... 

Les proprietes correspondent d des contraintes ou d des informations complementaires, 
comme les exceptions, les pre-conditions, les post-conditions, ou encore I'indication qu'une 
classe est abstraite, etc. 

UML 2 autorise egalement la definition des operations dans n'importe quel langage d 
condition que celui-ci soit precise a priori. Vous pouvez, par exemple, utiliser la syntaxe du 
langage C++ ou du langage Java pour exprimer toutes les methodes des classes. 
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2.6 Operations de classe 



Comme pour les attributs de classe, vous aurez peut-etre besoin de defmir une operation 
qui ne depend pas des valeurs propres de chaque objet, mais qui porte sur les attributs de la 
classe ou uniquement sur les parametres de l'operation. Dans ce cas, Foperation devient 
propriete de la classe, et non de ses instances. Elle n'a pas acces aux attributs des objets de la 
classe. Graphiquement, une methode de classe est soulignee. 



EXEMPLE L'execution d'une application cree plusieurs objets de la classe Processus. Pour afficher le 

nombre d'objets de cette classe disponible simultanement dans le systeme, vous pouvez ajou- 
ter un attribut de classe qui compte le nombre de processus (lors de la creation et de la des- 
truction des objets) et une methode qui affiche ce nombre. 



Figure 2.7 

Operation de classe 
et stereotype 
d'operation. 



Processus 



+ nom : String 

- nombreProc : integer 



« constructeurs » 

+ afficheNombreProcO : v °id - 



Le nombreProc est un attribut de classe prive. 
Contrairement au nom qui est associe a chaque 
processus, le nombreProc n'est disponible qu'en 
un seul exemplaire. II est associe a la classe. 
Les « . . . » indiquent que tous les attributs ne sont 
pas representes. 



Le stereotype type de methodes est utilise pour j^N, 
simplifier la notation ou lorsque les operations ou 
leurs signatures ne sont pas encore connues, 



La methode afficheQ est une methode de classe. 
Elle est publique et ne renvoie aucune valeur. 



2.7 COMPARTIMENTS COMPLEMENTAIRES D'UNE CLASSE 



Le processus de modelisation se fait pas a pas. De ce fait, lors de la construction des classes, 
les caracteristiques ne sont pas toutes connues de facon precise. Pour prendre en compte 
cette construction incrementale, vous ajoutez des informations complementaires aux clas- 
ses telles que les responsabilites, les contraintes generales, les exceptions, etc. 

Pour ce faire, vous disposez de deux nouveaux compartiments dans la description graphi- 
que d'une classe, a savoir le compartiment des responsabilites et celui des exceptions. Si la 
modelisation concerne une application informatique a implementer, ces deux compar- 
timents disparaitront quand vous arriverez a la phase de generation de code ; ils seront 
transformed en un ensemble d'attributs et de methodes. 



EXEMPLE La classe Connexionlnformatique doit respecter une charte definissant les modalites de 

connexion. Dans un premier temps, cette charte n'est ni une methode, ni un attribut : il s'agit 
d'une responsabilite de la classe. Dans la description de cette classe, comme le montre la 
figure 2.8, il faut aussi gerer le cas ou la connexion est impossible. 
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Figure 2.8 

Compartiment 
de responsabilite 
et d'exception. 



Connexion 



+ip : Byte [4] 



Respecter la charte 
Posseder une adresse IP 



+ seConnecter( ...) 



« exceptions » 
Connexion impossible 



Compartiment des responsabilites 
enumerant V ensemble des taches devant 
etre assurees par la classe. 



Enumere les situations exceptionnelles et \^^< 
~ — — — I les anomalies devant etre gerees par la classe. 



B Interface 

Le role d'une interface est de regrouper un ensemble d'operations assurant un service cohe- 
rent offert par un classeur et une classe en particulier. 

Le concept d'interface est essentiellement utilise pour classer les operations en categories 
sans preciser la maniere dont elles sont implementees. La definition d'une interface ne spe- 
cific pas - contrairement a celle d'une classe - une structure interne et ne precise pas les 
algorithmes permettant la realisation de ses methodes. Elle peut preciser les conditions et 
les effets de son invocation. Une interface n'a pas d'instances directes. Pour etre utilisee, 
elle doit etre realisee par un classeur, qui est souvent une classe. Une interface peut etre spe- 
cialised et/ou generalisee par d'autres interfaces. 

La realisation d'une interface par une classe est representee graphiquement par un trait dis- 
continu qui se termine par une pointe triangulaire. Une maniere simplifiee de representer 
une interface consiste a placer un petit cercle, souvent appele « lollipop » (sucette), rattache 
a la classe qui realise l'interface, comme le montre la figure 2.9. 



Specification 

Une interface est definie comme une classe, avec les memes compartiments. Les principals 
differences sont la non-utilisation du mot-cle abstract, car l'interface et toutes ses methodes 
sont, par definition, abstraites, et I'ajout du stereotype interface avant le nom de l'interface. 



Figure 2.9 

Deux manieres de 
representer l'interface 
et le lien avec la classe 
qui la realise. L'interface 
Nomlnterface est 
realisee par la classe 
NomClasse. 



« interface » 
Nomlnterface 



NomClasse 



— 0 

Nomlnterface 



NomClasse 



EXEMPLE Selon des criteres a definir a posteriori, les objets de la classe Hotel et les objets de la classe 

Personne doivent etre comparables. L'operation qui compose l'interface et permet la compa- 
raison entre les instances des classes Personne et Hotel doit etre la mime. Cependant, les 
criteres de comparaison sont, evidemment, differents. La figure 2.10 modelise cette interface 
commune, realisee par chacune des classes derivees. 



UML2 



Figure 2.10 

Les classes Hotel 
et Personne realisent 
I'interface Comparable. 



Hotel — 



« realize » 



Personne — ' 



« interface » 
Comparable 



-P> CompareTo() : Integer 

« realize » 



Hotel 



Personne 



— o 

Comparable 



— o 

Comparable 
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Quand une classe depend d'une interface (interface requise) pour realiser ses operations, 
elle est dite « classe cliente de I'interface ». Graphiquement, cela est represente par une rela- 
tion de dependance entre la classe et I'interface. Une notation lollipop equivalente est aussi 
possible, comme le montre la figure 2.1 1. 



Figure 2.1 1 

La classe NomClasse 
depend de I'interface 
Nomlnterface. 



« interface » 
Nomlnterface 



NomClasse 



<o 



Nomlnterface 



NomClasse 



□ Relations entre classes 

Les classes sont les elements de base du diagramme de classes. Une application necessite 
evidemment la modelisation de plusieurs classes. Apres avoir trouve les classes, il convient 
de les relier entre elles. Les relations entre classes expriment les liens semantiques ou struc- 
tured Les relations les plus utilisees sont l'association, l'agregation, la composition, la 
dependance et l'heritage. Dans la plupart des cas, ces relations sont binaires (elles relient 
deux classes uniquement). 

Meme si les relations sont decrites dans le diagramme de classes, elles expriment souvent les 
liens entre les objets. De ce fait, meme les relations binaires entre classes peuvent faire inter- 
venir plusieurs objets de chaque classe. La notion de multiplicity permet le controle du 
nombre d'objets intervenant dans chaque instance de la relation. 

4.1 MULTIPLICITE 



Dans le metamodele UML, la multiplicite est definie par un ensemble non vide d'entiers 
positifs a l'exclusion d'un ensemble ne contenant que zero {0}. Elle apparait a chaque extre- 
mite d'une relation et indique le nombre d'objets de la classe apparaissant a cette extremite 
pouvant s'associer a un seul et unique objet de la classe apparaissant a l'autre extremite. 



EXEMPLE Un objet de la classe Voiture est compose d'au moins trois roues et d'au plus dix roues. Pour 

ajouter cette information dans le diagramme de classes, on ajoutera le lien de composition 
entre les classes Voiture et Roue et on ajoutera la multiplicite [3. .10] du cote de la classe 
Roue. 



Voiture 




3.. 10 


Roue 





multiplicite. 
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Cette relation entre deux classes indique qu'un objet de la classe Voiture doit etre compose 
de trois a dix objets de la classe Roue. 

Les principales multiplicites normalisees sont « plusieurs » (*), « exactement n » (n), « au 
minimum n » (n . . *) et « entre n et m » (n . . m). II est aussi possible d'avoir un ensemble 
d'intervalles convexes: n1 . . n2, n3 . . n4 ou n1 . . n2, n5, n6..*, etc. 



4.2 Association 



Une association represente une relation semantique entre les objets d'une classe. Elle est 
representee graphiquement par un trait plein entre les classes associees. Elle est completee 
par un nom qui correspond souvent a un verbe a 1'infinitif, avec une precision du sens de 
lecture en cas d'ambiguite. Parfois, un stereotype qui caracterise au mieux l'association 
remplace le nom. Chaque extremite de l'association indique le role de la classe dans la 
relation et precise le nombre d' objets de la classe qui interviennent dans l'association. 
Quand l'information circule dans un sens uniquement, le sens de la navigation est indique 
a l'une des extremites. UML 2 donne, aussi, la possibilite d'exprimer la non-navigabilite 
d'une extremite par l'ajout d'une croix sur l'association, comme le montre la figure 2.15. 



Figure 2.1 3 

L'association 
et ses differents 
ornements. 



multiplicite 



role 



multiplicite 



role 



Indique le sens de lecture du \^^. 
nom ou du stereotype. Dans le cas 
d'un stereotype, ce dernier est mis 
entre guillemets. 



EXEMPLE Association 

Une personne travaille pour une et une seule entreprise. L'entreprise emploie au moins une 
personne. L'entreprise est I'employeur des personnes qui travaillent pour elle et une personne 
a un statut d'employe dans l'entreprise. 



Figure 2.14 

Role, multiplicite et 
nom de l'association 
sans restriction de 
navigabilite. 



Personne 


1..* travailler pour 1 


Entreprise 




employe employeur 



EXEMPLE 



Association avec navigabilite et contraintes 

Un polygone est defini par un ensemble de points jouant le role de sommets. Les sommets du 
polygone ne sont accessibles que par la classe et par ses descendants. Par ailleurs, il est inu- 
tile et encombrant que les points aient un lien vers le polygone et, de maniere generale, vers 
les figures auxquelles ils appartiennent. 



Figure 2.1 5 
Association orientee. 



Polygone 


^-x — 


defini par 


3^ 


Point 






#sommet 



La navigation est possible uniquement du polygone vers les points. 

Vous pouvez modeliser l'association entre les classes Polygone et Point et mettre en evidence 
la navigabilite de l'association en ajoutant un attribut sommet dans Polygone (figure 2.16). 
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Exemple de 
modelisation 
de la navigation 
par des attributs. 



Chapitre 



Cependant, la classe Point ne doit pas avoir d'attribut de type Polygone, ni de methode qui 
renvoie les polygones definis par ce point. 



Polygone 



#sommets : Point[3..*] 



L' association la plus utilisee est l'association binaire (reliant deux classeurs). Parfois, les 
deux extremites de l'association pointent vers le meme classeur. Dans ce cas, l'association 
est dite « reflexive ». 



Figure 2.1 7 

Exemples 

dissociations 

reflexives. 



a le meme age 



+parent 

2 D 



Personne 



+enfant 



i — *r 



□ 



amie de 



La premiere est asymetrique (parent de), la deuxieme est symetrique et non transitive (amie 
de) et la derniere est a la fois symetrique et transitive. II est conseille d'ajouter les roles des 
extremites dans le cas des relations asymetriques. 

L'association reflexive entre classes a pour principale fonction de structurer les objets d'une 
meme classe. Quand l'association est asymetrique, elle permet de creer une hierarchie entre 
les objets sinon elle partitionne les instances de la meme classe. Quand l'association est a la 
fois symetrique et transitive, les objets sont regroupes en classes d'equivalence. Dans l'exem- 
ple de la figure 2.17, l'association reflexive « parent de » permet de creer un arbre (hierar- 
chie) genealogique entre les instances de la classe Personne. La relation symetrique et 
transitive « a le meme age » permet de regrouper les objets de la classe Personne en classes 
d'equivalence (toutes les personnes ayant le meme age appartiendront au meme groupe). 

Remarque 

De nombreux concepts sont definis autour de la notion d'association. Nous avons selectionne 
cinq concepts qui nous paraissent importants : l'association avec contraintes, l'association 
derivee, la classe-association, la classe representante (ou qualifiante) et l'association n-aire 
(n > 2). 




4.3 Association avec contraintes 



Une association entre classes indique que des proprietes sont echangees ou partagees par les 
classes reliees. L'ajout de contraintes a une association ou bien entre associations apporte 
plus d'informations car cela permet de mieux preciser la portee et le sens de l'association. 
Les contraintes sont mises entre accolades et peuvent etre exprimees dans n'importe quel 
langage. Cependant, il est preferable d'utiliser le langage OCL (Object Constraint Language) . 
Le premier exemple de la figure 2.18 montre une association entre un polygone et ses som- 
mets en precisant que les sommets d'un polygone sont ordonnes, ce qui permet de reduire 
a 1 le nombre de figures pouvant etre dessinees a partir de n sommets. Le deuxieme exemple 
montre une contrainte entre deux associations : elle indique que le responsable du departe- 
ment fait necessairement partie du personnel. 
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Figure 2.1 8 

Exemples 
dissociations 
dont la portee 
est restreinte par 
les contraintes 
du langage OCL. 
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Point 




#sommet 





Departement 



emploie 



(subset}! 



( ordered ) 



est responsable 



Element du langage OCL qui [^i. 
indique que les sommets, dans un 
polygone, sont ordonnes. 



Personne 



4.4 Association derivee 



Une association derivee est conditionnee ou peut etre deduite a partir d'une autre associa- 
tion. Souvent un ensemble de contraintes, exprimees en OCL, est ajoute a une association 
derivee pour definir les conditions de derivation. Graphiquement, une association derivee 
est symbolisee par l'ajout d'un slash avant le nom de l'association. Dans l'exemple de la 
figure 2.19, l'association derivee /emploi indique que la personne qui travaille pour une 
entreprise est la meme que celle qui est associee a l'un de ses departements. 



Fic 



2 19 



Association derivee 
definie par une 
contrainte du 
langage OCL. 



/emploie 



Entreprise 


{Context : Personne 


Personne 




_ self.departement. entreprise / 










Cette contrainte suppose que la classe 
Personne contienne un attribut de la classe 
Departement et que la classe Departement 
contienne un attribut de la classe Entreprise 



4.5 Classe-association 



Une association peut etre raffinee et avoir ses propres proprietes, qui ne sont disponibles 
dans aucune des classes quelle lie. Comme, dans le modele objet, seules les classes peuvent 
avoir des proprietes, cette association devient alors une classe appelee « classe-association ». 
A partir du moment ou elle est definie, elle est consideree comme toutes les autres classes du 
modele. 



EXEMPLE Les personnes qui travaillent dans une entreprise occupent un poste. Parmi les proprietes asso- 

ciees au poste figure le salaire. Par ailleurs, quand une personne occupe un poste dans une 
entreprise, elle peut etre responsable de plusieurs personnes. 



Figure 2.20 

Une classe- 
association est 
caracterisee par 
l'ajout d'un trait 
discontinu entre 
la classe et 
l'association 
qu'elle represente. 





► 




Personne 




Entreprise 




1 




employe employeur 



Association 
reflexive orientee 



Poste 



salaire : Salaire 



responsable 



Classe association 



ion [••'^j 



UML2 



Chapitre 

4.6 Association quaufiee 



Parfois, l'association entre deux classes donne peu d'indications sur l'implication effective 
des classes dans la relation, ce qui rend la modelisation imprecise. Cette imprecision concerne, 
en particulier, la multiplicite d'une extremite de l'association et/ou la portee de l'association 
par rapport aux classes associees. 

La qualification d'une association permet, dans certains cas, de transformer une multipli- 
cite indeterminee ou infmie en une multiplicite finie, comme le montre la figure 2.21. 



EXEMPLE 



Changement de multiplicite avec un qualificateur 

La classe Vector du langage Java permet de referencer un ensemble quelconque d'objets de 
la classe Object. On suppose qu'un objet est reference une seule fois. La figure 2.21 donne 
une modelisation de cette situation avec et sans qualificateur. Un objet de la classe Object est 
reference par un indice de type integer. 



Figure 2.21 

Interet de la 

aualification d'une 
asse pour preciser 
la multiplicite. 



Vector 


1 * 


Object 
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indice:integer 
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1 


Object 







EXEMPLE Qualification d'une association pour limiter son impact sur les classes associees 

L'objectif est de modeliser l'association entre une personne et une banque. L'unique lien entre 
les deux est le fait de posseder au plus deux comptes. La banque assure bien d'autres activi- 
tes qui ne concernent pas le client. Pour mettre en evidence le fait que le lien entre la banque 
et une personne se limite d la possession de plusieurs comptes, on ajoute une classe Compte 
qui represente la classe Banque dans l'association avec la classe Personne. 



Figure 2.22 

Une classe aualifiante 
est collee a la classe 
principale. 



Banque 



#Compte 



0..2 



posseder 
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4.7 Association n-aire 



Une association n-aire lie plus de deux classes. La gestion de ce type d'association est tres 
delicate, notamment quand on ajoute la multiplicite (voir exercice 5). Pour cette raison, 
elles sont tres peu utilisees. On leur prefere des associations binaires combinees avec des 
contraintes du langage OCL. 



Notation 

Les traits pleins qui viennent de toutes les classes associees convergent vers un losange cen- 
tral pouvant eventuellement accueillir une classe-association. La multiplicite apparaissant 
sur le lien de chaque classe s'applique sur une instance du losange. Une instance du 
losange par rapport d une classe est un ensemble contenant une seule et unique instance 
de chacune des classes, d I'exclusion de la classe-association et de la classe consideree. 
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EXEMPLE 



Chaque annee, les etudiants s'inscrivent dans un seul groupe et suivent des modules. Pour un 
groupe d'etudiants donne (ne depassant pas vingt-cinq individus), un module est assure 
par un seul enseignant. Un module n'ouvre que si au moins quatre etudiants sont inscrits. Par 
ailleurs, la politique de I'ecole fait qu'un enseignant ne peut pas assurer plus de trois modules 
pour un etudiant donne et un etudiant suit entre cinq et dix modules. 



Figure 2.23 

Relation entre trois 
classes (relation 
ternaire). 




4.8 Relation d'agregation 



Une agregation est une forme particuliere d'association. Elle represente la relation d'inclu- 
sion structurelle ou comportementale d'un element dans un ensemble. Contrairement a 
l'association, l'agregation est une relation transitive. 



Notation 

Une agregation se distingue d'une association par I'ajout d'un losange vide du cote de 
I'agregat. 



EXEMPLE 



Figure 2.24 

Relation 
d'agregation. 



Une ecole dispose d'au moins une salle de cours. Dans chaque salle, on trouve des chaises et 
un video-projecteur fixe au plafond. 



Ecole ^ 



Salle $ 



I 



Chaise 



Projecteur 



L'agregation permet egalement la delegation d'operation : une operation definie comme 
pouvant etre realisee par une classe est en realite realisee par ses parties. Par exemple, on 
realisera l'operation de nettoyage d'une ecole en deleguant cette tache a toutes ses salles. La 
duree de vie de I'agregat est independante des elements qui le constituent. La destruction 
d'une instance de la classe Salle n'implique pas la destruction des instances de la classe 
String. Par ailleurs, un composant peut apparaitre dans plusieurs agregats (pas de restric- 
tion sur la multiplicite du cote de I'agregat). Une instance de la classe Projecteur peut etre 
partagee par plusieurs salles. 



4.9 Relation de composition 



La composition, appelee egalement « agregation composite », est une agregation particuliere. 
Cela signifie que toute composition peut etre remplacee par une agregation, qui elle-meme 
peut etre remplacee par une association. La seule consequence est la perte d'informations. 

La relation de composition decrit une contenance structurelle entre instances. Ceci impli- 
que, en particulier, que l'element composite est responsable de la creation, de la copie et de 
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la destruction de ses composants. Par ailleurs, la destruction ou la copie de l'objet compo- 
site implique respectivement la destruction ou la copie de ses composants. Une instance de 
la partie appartient toujours a au plus une instance de l'element composite. 

Notation 

Une composition se distingue d'une association par I'ajout d'un losange plein du cote de 
I'agregat. La multiplicite du cote de I'agregat ne peut prendre que deux valeurs : 0 ou 1 . 
Par defaut, la multiplicite vaut 1 . 



EXEMPLE 



Comme tous les autres elements du langage UML, la composition ne reflete pas forcement la 
realite. Cependant, elle doit etre fidele a la situation modelisee, comme le montre ce qui suit. 

On peut completer I'exemple precedent en indiquant qu'une salle est composee d'une seule 
porte et de plusieurs fenetres. De plus, si le tableau est fixe, on considere que la relation de 
composition reflete mieux le lien qui le lie a la salle. 



Figure 2.25 

Exemple de relation 
de composition. 
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Remarque 

La relation de composition etant structurelle, le langage UML autorise la representation suivante : 



Figure 2.26 

Representation imbriquee 
de la composition. Une salle 
est composee d'une porte 
et de plusieurs fenetres. 

4.10 Relation de dependance 
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Exemple 



Une dependance est une relation unidirectionnelle exprimant une dependance semantique 
entre les elements du modele. Elle est representee par un trait discontinu oriente. Elle indi- 
que que la modification de la cible implique le changement de la source. La dependance est 
souvent stereotypee pour mieux expliciter le lien semantique entre les elements du modele. 
Les stereotypes normalises sont, entre autres, « friend » (on accorde une visibilite speciale a 
la classe source dans la cible), « derive » (la source est calculee a partir de la cible), « appel » 
(appel d'une operation par une autre), « instantiate » (une operation de la source cree une 
instance de la cible), « send » (une operation envoie un signal vers un element cible), 
« trace » (la cible est une version precedente de la source), « refine », « copie » et « create ». 

Le deroulement des cours depend des cours. 



Figure 2.27 

Relation de dependance. 
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4.11 Relation d'heritage 



Un des interets de la modelisation objet est la possibilite de manipuler des concepts abs- 
traits. Cette notion est tres importante car elle permet de simplifier la representation. Elle 
est, par ailleurs, proche de la facon dont on modelise le monde : continuellement, sans 
meme s'en rendre compte, on fait abstraction de certaines choses : par exemple, quand on 
parle d'un vehicule, c'est une vue de l'esprit ; dans la realite, il s'agit de voitures, de camions, 
etc. Les camions se distinguent par des marques, des tallies differentes, etc. Ces differents 
niveaux d'abstraction permettent, entre autres, de simplifier le langage et de factoriser les 
proprietes. 

Ce principe d'abstraction est assure par le concept de l'heritage. Ce concept permet tout 
simplement de partitionner recursivement les objets en ensembles d'ensembles. Quand les 
partitions sont grossieres, on les raffme (specialisation) et quand elles sont tres fines, on 
les generalise. Chaque partition est modelisee par une classe. 

Ce processus de generalisation et de specialisation est souvent guide par le sens semantique 
donne a chaque partition d'objets et a la granularite de la modelisation. 

En UML, la relation d'heritage n'est pas propre aux classes. Elle s'applique a d' autres elements 
du langage UML, comme les paquetages ou les cas d'utilisation. 



EXEMPLE Les animaux sont des etres vivants qui ont tous une duree de vie limitee. L'etre humain est un 

animal dont la duree de vie ne depasse pas cent cinquante ans. 

Dans cet exemple, l'ensemble des objets considered est celui de la classe Animal. Celle-ci est 
une specialisation de la classe EtreVivant dont elle reprend la propriete dureeDeVie. Le par- 
titionnement des objets de la classe Animal fait apparaitre la partition representee par la 
classe EtreHumain. L'information specifique de cette classe est la duree de vie qui ne depasse 
pas cent cinquante ans. 



La classe EtreVivant est dite 
classe parent ou superclasse 
de la classe Animal. La classe 
EtreHumain est dite classe 
enfant, classe derivee ou sous- 
classe de la classe Animal. 



Comme le montre l'exemple, l'heritage simplifie la modelisation en utilisant les principes 
d'abstraction et de decomposition. L'abstraction consiste a defmir une hierarchie de sous- 
problemes devant etre traites en fonction de leur importance. La decomposition, quant a 
elle, consiste a defmir un ensemble de sous-problemes pouvant etre traites separement. 

La specialisation de classes consiste a reduire le domaine de definition des objets. Cela se fait 
principalement de deux manieres : en ajoutant de nouveaux attributs, independants de ceux 
existants, ou en reduisant le domaine de definition des attributs existants. 



EXEMPLE Un rectangle et un cercle sont des figures geometriques. Un carre est un rectangle dont la lon- 

gueur et la largeur sont identiques. 

Les classes decrivant cette situation sont FigureGeometrique, Rectangle, Carre. La classe 
Rectangle specialise FigureGeometrique en ajoutant des attributs et la classe Carre specia- 
lise la classe Rectangle en reduisant le domaine de definition des attributs existants (largeur 
= longueur). 



Exemple d'une 
relation d'heritage. 




EtreHumain 
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Figure 2.29 

Exemple d'une 
relation d'heritage. 



FigureGeometrique 



Rectangle 



largeur: integer 
longueur: integer 



Cercle 



La liste suivante donne quelques proprieties de l'heritage : 

• La classe enfant possede toutes les proprietes de ses classes parents. Mais elle n'a pas acces 
aux proprietes privees de celles-ci. 

• Une classe enfant peut redefinir (meme signature) une ou plusieurs methodes de la classe 
parent. Sauf indications contraires, un objet utilise les operations les plus specialisees 
dans la hierarchie des classes. La surcharge d'operations (meme nom, mais signatures des 
operations differentes) est possible dans toutes les classes. 

• Toutes les associations de la classe parent s'appliquent, par defaut, aux classes derivees. 

• Une instance d'une classe peut etre utilisee partout ou une instance de sa classe parent est 
attendue (principe de la substitution). Par exemple, toute operation acceptant un objet 
d'une classe Animal doit accepter tout objet de la classe Chat (l'inverse n'est pas toujours 
vrai). 

• Une classe peut avoir plusieurs classes parents. On parle alors d'heritage multiple. Le 
langage C++ est un des langages objet permettant son implementation effective. Ce 
mecanisme est largement considere comme une source d'erreurs, en raison de la com- 
plexity des relations entre attributs qu'il introduit. 



Remarque 

Lors de la redefinition d'un attribut d'une classe dans une sous-classe, il est fortement 
conseille de le faire uniquement en restreignant son domaine de definition. Deux cas sont 
possibles : soit garder le meme type et reduire le champ des valeurs, soit redefinir I'attribut 
comme objet d'une sous-classe de sa classe precedente. Dans le cas de la redefinition de 
methode, celle-ci est utilisee afin de restreindre les arguments (en fixant certains), en etendant 
la definition initiale de la methode, en proposant d'autres alternatives d'implementation 
(par exemple pour optimiser le temps de calcul). 




EXEMPLE Heritage multiple 

Un bateau est a la fois un vehicule a moteur et un vehicule marin. Si les classes VehiculeA- 
Moteurel VehiculeMarin existent, il est souhaitable d'indiquer que le bateau herite de I'une et 
de I'autre et de profiter ainsi de toutes les proprietes dejd definies. Cependant, la question se 
pose de savoir quelle est la propriete associee d I'objet lorsque celle-ci apparaTt dans les 
deux parents directs. La solution la plus simple consiste d definir une priorite d'heritage. 
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Figure 2.30 

Exemple d'heritage 
multiple. 







Si on donne la priorite au 
VehiculeMarin alors le type du 
nom dans Bateau sera String. 


Bateau 





VehiculeMarin 



nom: String 



VehiculeMoteur 



nom: Char [1..10] 



Remarque 

Quand une classe (ou une operation) ne peut etre redefinie, il faut ajouter la propriete 
{leaf} d la definition de la classe ou de I'operation. L'exercice 5 presente certaines proprie- 
tes de la relation d'heritage. 



0 Connecteurs, signaux et ports 



Les connecteurs specifient les liens de communication possibles entre les instances de 
classeur. Ces liens peuvent correspondre a des instances d'association ou a des communica- 
tions via des passages de parametres, des appels d'operation, etc. Une connexion peut etre 
realisee par un simple pointeur ou par un reseau de communication complexe. 

Le port est une propriete d'un classeur lui permettant de preciser ses points d'interaction 
avec son environnement ou bien, parfois, avec ses propres parties. Les ports sont connectes 
via des connecteurs. lis peuvent specifier les services d'un classeur ou les services qu'il 
attend de son environnement. Deux principaux types de ports existent : le port protocole, 
qui decrit les connectiques interne et externe d'un classeur (souvent classe active), et le port 
comportemental, qui est directement associe a la machine d'etats (automate) du classeur 
qui porte ce port. 

Un signal modelise un message asynchrone echange entre les instances. II est caracterise 
par un nom et un ensemble d'attributs qui correspondent aux donnees transporters par le 
signal. 



Figure 2.31 

Representations 
graphiques d'un 
connecteur, d'un 
port et d'un signal. 
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□ Diagramme d'objets 

Bien souvent, la description statique d'un systeme est faite a travers le diagramme de classes. 
Cela permet de simplifier la modelisation en synthetisant les caracteristiques communes et 
en couvrant un grand nombre d'objets. Parfois, il est utile, voire necessaire, d' ajouter un 
diagramme d'objets. Le diagramme d'objets permet, selon les situations, d'illustrer le 
modele de classes (en montrant un exemple qui explique le modele), de preciser certains 
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aspects du systeme (en mettant en evidence des details imperceptibles dans le diagramme de 
classes), d'exprimer une exception (en modelisant des cas particuliers, des connaissances 
non generalisables . . . ) ou de prendre une image (snapshot) d'un systeme a un instant donne. 

Le diagramme de classes modelise les regies et le diagramme d'objets modelise des faits. 
Souvent, le diagramme de classes sert de modele pour instancier les classeurs arm d'obtenir 
le diagramme d'objets. Le diagramme de classes de la modelisation d'une entreprise montre 
qu'une entreprise emploie au moins une personne et qu'une personne travaille dans au plus 
deux entreprises (figure 2.31(a)). En revanche, le diagramme d'objets modelise l'entreprise 
qui emploie trois personnes (figure 2.31(b)). 



Figure 2.32 

Diagramme de 
classes et exemple 
de diagramme 
d'objets associe. 
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Les deux principaux classeurs instancies dans le diagramme d'objets sont les classes et les 
relations. 



6.1 Representation des objets 



Graphiquement, un objet se represente comme une classe, avec deux compartiments, celui 
du nom et celui des attributs. Le compartiment des operations des classes n'est pas utile 
dans les objets puisque l'interpretation des operations est la meme pour tous les objets et 
que tous les objets d'une classe possedent les memes operations. 

Contrairement au nom d'une classe, le nom d'un objet est souligne et son identifiant peut 
etre ajoute devant le nom de la classe. Les attributs recoivent des valeurs. Quand certaines 
valeurs d'attribut d'un objet ne sont pas renseignees, on dit que l'objet est partiellement 
defini (figure 2.33(a)). 

Parmi les differentes formes d'objet, on trouve les instances nominees (figure 2.33(b)), les 
instances anonymes avec indication de paquetage (figure 2.33(c)), les instances multiples 
(figure 2.33(d)), les instances orphelines (figure 2.33(e)) et les instances stereotypees 
(figure 2.33(g)). La figure 2.33(f) montre un objet sans valeur d'attribut, mais avec un etat 
explicite. Cela est particulierement utile lorsque plusieurs valeurs des attributs d'un objet 
correspondent a une seule interpretation semantique. A la figure 2.33(f), l'etat « grand » cor- 
respond a toutes les valeurs de l'attribut taille superieure a un metre quatre-vingts, par 
exemple. 



Figure 2.33 

Exemples d'instances 
d'objet. 
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6.2 Instances de relation 



Un diagramme de classes contient essentiellement des classes et des relations entre classes. 
Quand un diagramme d'objets est cree a partir d'un diagramme de classes, les classes sont 
instanciees et deviennent des objets, tandis que les relations deviennent des liens au 
moment de leurs instanciations. Graphiquement, un lien se represente comme une relation, 
mais le nom de la relation est souligne. L'exemple de la figure 2.34 indique que le portable 
achete par Jean est compose d'un ecran et est livre avec une alimentation. 



Figure 2.34 

Instances de relation 
montrant des instances 
d'association, 
de composition 
et d'agregation. 



SonyVaiol :Portable 



:Alimentation :Ecran 



6.3 Relation de dependance d'instanciation 



La relation de dependance d'instanciation decrit la relation entre un classeur et ses instances. 
Elle relie, en particulier, les associations aux liens et les classes aux objets, comme le montre 
la figure 2.35. 



Figure 2.35 

Dependances 
d'instanciation 
entre les classeurs 
et leurs instances. 



Enseignant 


1..* dormer cours 1..* 


Etudiant 





I 

l«instanceof» 
I 



: Enseignant 



I 

donner cours 



«instanceof» 



«instanceof» 



I 



:Etudiant 



□ Gontraintes 

Les contraintes permettent de rendre compte des details que n'expriment pas les elements 
du langage UML afin de restreindre la portee du modele. En UML, les contraintes sont vues 
comme un mecanisme d'extension. Elles sont exprimees par une expression mathematique, 
un langage de programmation, le langage naturel, etc. Cependant, un langage d'expression 
des contraintes est maintenant associe a UML et permet d'exprimer la plupart des 
contraintes : il s'agit du langage OCL. OCL permet d'exprimer principalement quatre types 
de contraintes : les invariants, les pre-conditions et les post-conditions a l'execution d'ope- 
rations ainsi que les conditions de garde. 

Dans le diagramme de classes, les contraintes les plus couramment utilisees permettent de 
specifier les valeurs initiales d'un objet ou d'une extremite d'une association, de specifier 
les regies d'heritage ({complete}, {incomplete}, {overlaps}, {distinct}, ...), de specifier une 
methode, de restreindre la portee d'une association ({subset}, {xor},...), d'exprimer le 
mode devolution des objets ({frozen}, {addOnly}, ...), leur organisation ({ordered}, 
{frozen}, ...). 

Dans le cadre d'UML 2, les specifications du langage OCL figurent dans un document inde- 
pendant, decrivant en detail la syntaxe formelle et la facon d'utiliser ce langage. 



UML 2 



Chapitre 



EXEMPLE 



1 . Un comite est compose d'au moins deux personnes. Le comite est preside par un de ses 
membres. 

2. Un polygone est compose d'une serie d'au moins trois sommets ordonnes. Chaque sommet 
est un point. 

3. Une voiture peut avoir entre trois et dix roues. Durant la vie d'une instance de la classe 
Voiture, le nombre de roues ne change jamais. 



Figure 2.36 

Exemple d'utilisation 
des contraintes 
pour affiner la 
modelisation. 



Comite 



membre de 

2 * 



— ■( subset }- 



preside 



Personne 



Poly 


gone 


4 

ordered } 
3..* 


sommet 


Personne 



Voiture 



{frozen} 
2..* 



Roue 



Une contrainte, dans le modele de donnees, est associee au modele sauf si elle est associee a 
un stereotype. Dans ce dernier cas, la contrainte concerne le metamodele, et non le modele 
de donnees. Pour plus de details, reportez-vous au document normatif dedie au langage 
OCL. 



□ Construction d'un diagram me de classes 

La construction du diagramme de classes, comme celle des autres diagrammes, depend a la 
fois de l'objectif et de la finalite de la modelisation. Si on s'interesse a la finalite de la mode- 
lisation, souligne Steve Cook et John Daniels, il y a au moins trois points de vue qui guident 
la modelisation. 

• Le point de vue specification. Dans le domaine du logiciel, il met l'accent sur les interfa- 
ces des classes plutot que sur leurs contenus. 

• Le point de vue conceptuel. II capture les concepts du domaine et les liens qui les lient. II 
s'interesse peu ou prou a la maniere eventuelle d'implementer ces concepts et relations et 
aux langages d'implementation. 

• Le point de vue implementation. C'est le plus courant. L'objectif est de detailler le contenu 
et l'implementation de chaque classe. 

En fonction des objectifs fixes, vous obtiendrez des modeles eventuellement differents. Pour 
cette raison, il faut absolument situer le contexte de la modelisation avant de commencer la 
construction de tout diagramme. 

Une demarche couramment utilisee pour batir un diagramme de classes consiste a trouver 
les classes, puis les associations entre elles, a trouver ensuite les attributs de chaque classe, et 
enfin a organiser et a simplifier le diagramme en utilisant notamment le principe de genera- 
lisation. II faut reiterer ce processus afin d'ameliorer la qualite du modele. 

Trouver les classes du domaine. La premiere etape consiste, avec l'aide d'un expert du 
domaine, a trouver une liste de classes candidates. La demarche est souvent empirique. 
Dans un premier temps, ne soyez pas trop restrictif. Les classes correspondent souvent a des 
concepts ou a des substantifs du domaine. Parfois, elles correspondent a des operations : 
une transaction pour une banque est une classe, tout comme un appel telephonique pour 
un operateur de telephonic Neanmoins, une operation qui s'applique a un objet est rarement 
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une classe : payer ou appeler ne sont pas des bons choix, meme pour une banque ou un ope- 
rateur de telephonic 

Apres avoir etabli une premiere liste, eliminez les classes redondantes (celles qui modelisent 
des concepts similaires), ainsi que les classes superflues (celles qui ne sont pas en rapport 
direct avec le domaine). Le nom des classes est important ; il ne doit pas etre vague. Par 
exemple, EmployeDansEcurieDeCourseAutomobile est trop vague. Preferez Pilote et Mecani- 
cien. II faut cependant faire attention aux classes qui portent un nom de role : PremierPilote 
et DeuxiemePilote ne sont pas des bons choix. 

Le niveau de granularite d'une classe est important. Generalement, une classe contient plu- 
sieurs attributs. Si un substantif ne peut pas etre decompose en plusieurs entries, il s'agit 
bien souvent d'un attribut : un nom, par exemple, est considere comme un attribut d'une 
classe Personne, qui a par ailleurs d'autres attributs (Fage, le sexe...), tandis que l'auteur 
d'un livre ne peut pas se reduire a l'attribut d'une classe Livre, car l'auteur a un nom, une 
date de naissance, etc. 

Les classes ne doivent pas modeliser des implementations possibles d'elements du domaine : 
une liste de clients n'est pas une bonne idee de classe car vous pouvez creer un ensemble 
de clients de plusieurs facons, et pas seulement sous forme de liste. D'ailleurs, un modele 
contient rarement a la fois des classes et leurs conteneurs. Le modele d'une banque, par 
exemple, ne doit pas reunir simultanement les classes Clients au pluriel et Client au singu- 
lier, a moins qu'il soit important de constituer un portefeuille de clients. Dans ce cas, il faut 
avoir recours a deux classes, Client et PorteFeuilleDeClients et les associer par une relation 
de « un vers plusieurs ». 

Trouver les associations entre les classes. Les associations correspondent souvent a des verbes 
mettant en relation plusieurs classes, comme « est compose de », ou « pilote », ou bien 
encore « travail pour ». Les relations entre classes doivent etre modelisees par des asso- 
ciations, et non par des attributs (conducteur pour une classe Pilote est un mauvais 
choix d'attribut mais conduire en tant qu'association entre les classes Pilote et Voiture est 
approprie). 

Evitez les associations qui mettent en jeu plus de deux classes. Souvent, une association ter- 
naire peut etre transformed en une association binaire qualifiee. Par exemple, « un conducteur 
a besoin d'une assurance pour conduire une voiture » peut etre ramene a « un conducteur a 
une voiture et l'assurance est un attribut de l'association binaire entre conducteur et voiture ». 

Quand plusieurs classes sont associees, plusieurs chemins sont eventuellement possibles 
entre les classes. Le probleme qui se pose souvent est le suivant : faut-il limiter les chemins, 
ou au contraire, multiplier les associations en generalisant les raccourcis ? Multiplier les 
associations facilite l'utilisation des classes lors de l'implementation car il n'est pas neces- 
saire de parcourir de nombreuses associations pour acceder a une information. Cependant, 
multiplier n'importe comment les associations conduit a des chemins redondants, qui 
n'apportent aucune valeur ajoutee au diagramme de classes. De plus, multiplier les associa- 
tions reduit la reutilisabilite de l'application, car deux classes associees peuvent difficilement 
etre utilisees separement. Dans la plupart des cas, evitez les chemins redondants durant 
la phase d'analyse. II sera toujours temps, au moment de l'implementation, d'ajouter des 
chemins si vraiment cela facilite la programmation. 

Ne confondez pas une association avec un attribut car un attribut est propre a une classe 
tandis qu'une association met en jeu plusieurs classes. Dans certaines situations, cette regie 
intangible est violee de facon presque indiscernable. Considerez les deux classes Avion et 
Camion : devez-vous considerer "est plus lourd que" comme une association ? Non, car le 
plus simple est de placer un attribut « masse » dans chaque classe et d'utiliser une simple 
fonction de comparaison pour obtenir la reponse. 
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Trouver les attributs des classes. Les attributs correspondent generalement a des substantifs 
tels que « la masse d'une voiture » ou « le montant d'une transaction ». Les adjectifs tels 
que « rouge » ou des expressions telles que « 50 euros » representent souvent des valeurs 
d'attribut. Un attribut ne doit pas etre derive d'un autre attribut : l'age d'une personne, par 
exemple, peut etre deduit de sa date de naissance et de la date courante. 

Vous pouvez ajouter des attributs a toutes les etapes du cycle de vie d'un projet (implemen- 
tation comprise). N'esperez pas trouver tous les attributs des la construction du diagramme 
de classes. 

Organiser et simplifier le diagramme en utilisant l'heritage. Un heritage denote une relation 
de generalisation/specialisation entre plusieurs classes. Vous pouvez construire un graphe 
d'heritage « vers le bas », en partant d'une classe du domaine et en la specialisant en une ou 
plusieurs sous-classes, ou « vers le haut », en factorisant les proprietes de plusieurs classes 
pour former une classe plus generale. 

Cependant, ne confondez pas enumeration et heritage. Une enumeration est un type de 
donnees qui a un ensemble fini de valeurs possibles (les couleurs d'une voiture par exem- 
ple). Un heritage represente une relation de generalisation entre classes ; cela implique 
qu'une des sous-classes au moins a un attribut, une methode ou une association specifique. 

Tester les chemins d'acces aux classes. Suivez les associations pour verifier les chemins 
d'acces aux informations contenues dans les classes. Manque-t-il des chemins ou des infor- 
mations ? Si le monde a modeliser parait simple, le modele ne devrait pas etre complexe. 
Veillez a n'omettre aucune association. Cependant, ne cherchez pas a relier systematique- 
ment toutes les classes. Certaines peuvent tres bien etre isolees. 

Iterer et affiner le modele. Un modele est rarement correct des sa premiere construction. 
La modelisation objet est un processus, non pas lineaire, mais iteratif. Plusieurs signes 
denotent des classes manquantes : des asymetries dans les associations et les heritages, des 
attributs ou des operations disparates dans une classe, des difficultes a generaliser, etc. 

La demarche presentee dans cette section est une demarche indicative. Differents processus 
permettent la construction d'un diagramme de classes. Dans tous les cas, respectez les regies 
simples et efficaces suivantes : 

• Eliminez les classes redondantes. 

Un avion est associe d un aeroport de depart et d un aeroport d'arrivee. Une premiere mode- 
lisation permet d'obtenir trois classes : AeroportDepart, AeroportArrivee et /Avion (voir exer- 
cice 11). En realite, tous les aeroports jouent le role d'aeroport de depart pour certains 
avions et d'aeroport d'arrivee pour d'autres. II est done insense de garder deux classes 
Aeroport. On elimine la redondance en ne creant qu'une classe Aeroport et en modelisant 
les aeroports de depart et d'arrivee comme des roles des associations qui lient I'avion d 
I'aeroport. 

• Retardez l'ajout des classes faisant intervenir les choix de conception et de realisation. 

['application decrite dans I'exercice 1 indique que le systeme gere les salaries de I'entreprise. 
II n'est pas souhaitable d'introduire une classe FichierEmployes car cela impose un choix de 
realisation. Ce choix doit etre retarde dans la mesure du possible. 

• N'ajoutez pas les tableaux ou listes d'objets dans les classes. Souvent, cette information 
est explicitement visible dans les multiplicites associees aux relations entre les classes. 
Une bonne facon de representer la presence d'un tableau d'instances d'une classe dans 
une autre est d'utiliser les relations d'agregation ou de composition. 
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• Quand une classe dispose de beaucoup de responsabilites, trouvez un moyen de la sim- 
plifier (voir le principe d'abstraction et de decomposition). 

• Lors de la modelisation et du choix des relations entre classes, distinguez bien les objets 
physiques de leur description (du modele d'objets). 

• Une propriete structurelle (attribut) peut etre representee par une association, une 
description textuelle dans un classeur ou une combinaison des deux. 

• Evitez les operations d'acces aux attributs (get et set) car celles-ci ajoutent beaucoup de 
bruits et sont souvent inutiles. 

Pour des applications complexes, souvent plusieurs diagrammes de classes sont definis. 
Chaque diagramme met en evidence des parties particulieres du modele. Par exemple, un 
diagramme montre les classes appartenant a un paquetage, un autre montre les classes 
participant a la realisation d'un cas d'utilisation, etc. 



Conclusion 

Dans ce chapitre, nous avons d'abord defini la notion de classe et d'objet. Un objet repre- 
sente une entite concrete (par exemple un emplacement memoire dans un ordinateur). La 
classe, quant a elle, adopte un niveau plus eleve d'abstraction car elle modelise, d'une facon 
concise, un ensemble d'objets. Cependant, souvent le diagramme d'objets est neglige lors de 
la modelisation. C'est pourtant lui qui permet de definir les liens concrets entre les entites 
avant que ceux-ci ne soient generalises dans le diagramme des classes. Par exemple, l'asso- 
ciation reflexive de la figure 2.17 ne permet pas de donner le nombre exact d'objets mis en 
jeu. Plusieurs consequences peuvent en decouler. Par exemple, il n'est pas possible de definir 
la quantite de memoire a prevoir pour les instances de cette classe. 

Malgre leur importance, le diagramme de classes et le diagramme d'objets ont plusieurs 
limites a la bonne comprehension d'un systeme. Notamment, ils ne montrent pas le cycle de 
vie des objets : nous ne savons pas, a la lecture de tels diagrammes, dans quel ordre les objets 
sont crees, utilises puis detruits, pas plus qu'ils n'indiquent l'ordre dans lequel s'enchainent 
les operations. Neanmoins, le diagramme des classes est le plus utilise pour la modelisation 
d'un systeme car il en montre la structure interne. 

Avec le diagramme des cas d'utilisation, vu au chapitre 1, nous disposons, a present, de deux 
facons de voir un systeme. En effet, le diagramme des classes donne une approche objet tan- 
dis que celui des cas d'utilisation montre un cote fonctionnel. Mais, rien n'indique que ces 
deux modeles sont coherents entre eux : la structure interne donnee par le diagramme des 
classes supportera-t-elle les fonctionnalites prevues par les cas d'utilisation ? Ce passage du 
fonctionnel a l'objet est delicat. Une des solutions possibles pour garantir la coherence des 
deux modeles est de faire un decoupage en couches horizontales : la couche du bas decrit 
l'implantation du diagramme des classes et la couche du haut permet, via une interface 
(homme-machine et graphique par exemple), d'acceder aux fonctions de l'application. Le 
lien entre les deux couches est assure par l'adjonction d'une couche supplementaire (dite 
couche applicative). Une etude de cas, decrite a la fin de cet ouvrage detaille comment 
decomposer un systeme en couches. 



Chapitre 



Problemes 
et exercices 

Les exercices suivants utilisent les principaux concepts des diagrammes de classes. 



Exercice 1 Proprietes d'une classe 



Enonce 



Solution 



Proposez une modelisation, en vue d'une implementation informatique, de la situation 
suivante en mettant en evidence les differents compartiments et ornements des classes. 
Realisez la modelisation etape par etape, en faisant apparaitre, en fonction des connaissan- 
ces disponibles, les changements du modele. 

1. Une personne est caracterisee par son nom, son prenom, son sexe et son age. Les respon- 
sabilites de la classe sont entre autres le calcul de l'age, le calcul du revenu et le paiement 
des charges. Les attributs de la classe sont prives ; le nom, le prenom ainsi que l'age de la 
personne font partie de l'interface de la classe Personne. 

2. Deux types de revenus sont envisages, le salaire et toutes les sources de revenus autres 
que le salaire, qui sont tous deux represented par des entiers. On calcule les charges en 
appliquant un coefficient fixe de 15 % sur les salaires et un coefficient de 20 % sur les 
autres revenus. 

3 Un objet de la classe Personne peut etre cree, en particulier, a partir du nom et de la date 
de naissance. II est possible de changer le prenom d'une personne. Par ailleurs, le calcul 
des charges ne se fait pas de la meme maniere lorsque la personne decede. 



1. La modelisation implique la creation d'une classe Personne. Les attributs de la classe sont 
le nom, le prenom, le sexe et l'age. Dans l'approche objet, tout est objet ou classe. Sauf 
exceptions, les types des attributs sont aussi des classes. Meme si les types des attributs ne 
sont pas precises, definissez le nom et le prenom comme une chaine de caracteres (classe 
String). Partez du principe que le sexe peut avoir deux valeurs ('M' ou 'F') et que la date 
de naissance peut etre de type Date (classe Date). Cela impose evidemment l'existence 
des classes String et Date, sinon il faut les creer. Tous ces attributs sont prives. II faut done 
les faire preceder du modificateur d'acces private ou -. Les services offerts par cette classe 
sont le calcul de l'age, la possibility de voir le nom et le prenom d'une personne ainsi que 
le calcul des charges et du revenu. A cette etape, vous n'avez pas suffisamment d'infor- 
mations pour deduire les operations permettant le calcul des charges et du revenu ; elles 
resteront done dans le compartiment de responsabilites de la classe. Elles seront, par la 
suite, realisees par l'ajout d'un ensemble d'operations et/ou d'attributs. 
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Figure 2.37 
Classe Personne. 



Personne {etat :non 
validee ) 



- nom : String 

- prenom : String 

- sexe : {'F\ 'M'} 

- dateNaissance : Date 



+getNom : String 
+getPrenom : String 
+calculAge() : Date - 



Responsabilites 

- calcul revenu 

- calcul charges 



D'autres informations 
peuvent etre ajoutees comme 
l'auteur, la date, etc. 



Age = dateDuJour -DateNaissance 



Remarque 

Dans la solution proposee, la moderation de I'age est representee par un attribut date- 
Naissance et une methode calculAgefj. Une autre solution possible est de representer I'age 
par un attribut et de laisser au programmeur le choix d'un modele d'implementation. Dans 
ce cas, ajoutez I'attribut derive /age ; sa valeur sera alors calculee d partir d'une methode. 



2. Au vu de ces nouvelles informations, les responsabilites de la classe se transforment en 
proprietes de la maniere suivante : 

• Le calcul du revenu est represente par les attributs salaire et autreRevenu, avec eventuelle- 
ment deux methodes permettant la mise a jour de leurs valeurs. 

• Le calcul des charges est represente par deux attributs de classe, chargeSalaire et autre- 
Charge, et par une methode de calcul des charges (puisque celle-ci est bien detaillee dans 
l'enonce). 

Le calcul des charges est invalide en cas de deces de la personne. De ce fait, ajoutez un 
compartiment d'exceptions pour prevoir le traitement ulterieur de cette exception. 



Figure 2.38 

Ajout des operations 
a la classe Personne. 



Personne 



■ chargeSalaire :Float =0.15 
■autreCharge :Float =0.2 

- nom : String 

■ prenom : String 

■ sexe : {'F', 'M'} 

■ dateNaissance : Date 

- salaire : Integer 

• autreRevenu : Integer 



+getNom : String 
+getPrenom : String 
+calculAge() : Date 
+calculCharges () : Float 



La methode correspondante 
est : 

Renvoie (salaire * chargeSalaire 
+ autreRevenu * autreCharge) 



3. Pour creer un objet de la classe Personne, il faut par exemple disposer d'un nom et d'une 
date de naissance. Mais il est eventuellement possible de creer un objet personne en 
disposant d'autres informations. Au lieu d'ajouter le constructeur indique seul, ajoutez 
le stereotype constructor, qui permet a la fois d'organiser des operations en groupes et 
d'indiquer qu'il est possible d'ajouter d'autres constructeurs. 



UML2 



Figure 2.39 

Ajout du 
compartiment 
enumerant les 
exceptions. 



Chapitre 



Les operations assurant le changement des valeurs des attributs peuvent egalement etre 
regroupees sous le stereotype update. 

L'enonce indique que le calcul des charges ne s'applique plus si la personne est decedee. II 
s'agit, dans ce cas, d'une exception qui doit etre ajoutee dans le compartiment dedie afin 
quelle soit traitee lorsque les informations suffisantes seront disponibles. 



Personne 



- chargeSalaire :Float =0.15 
-autreCharge : Float =0.2 

- nom : String 

- prenom : String 

- sexe : {'F','M'} 

- dateNaissance : Date 

- salaire : Integer 

- autreRevenu : Integer 



« constructor » 
Personne (String nom, Date dNaissance) 

« update » 
-HsetPrenom (String prenom) 
+setAge(Date dNaissance) 

-HgetNom : String ^ ' 

-t-getPrenom : String ^ ' 

+calculAge() : Date y ' 

-HcalculCharges () : Float ' 



Exceptions 
Calcul charge si deces 



La methode correspondante est : 
Renvoie (salaire * chargeSalaire + 
autreRevenu * autreCharge) 



Exercice 2 Classe stereotypee 



Enonce 



En trigonometrie, on a besoin de calculer le sinus, le cosinus, la tangente des angles et la 
valeur du nombre PI. La classe Angle existe deja. Proposez une structure qui regroupe ces 
fonctions. 



Solution 



Les proprietes de l'enonce ne correspondent pas reellement a une classe. Mais pour des 
besoins d'implementation, par exemple, on peut vouloir les regrouper ensemble. UML offre 
un moyen de regrouper les variables et les operations globales sous forme d'une classe en 
utilisant le stereotype Utility. Ces classes sont dites « utilitaires » car elles ne repondent pas 
directement a un besoin fonctionnel mais contribuent a sa realisation. 



Figure 2.40 

Utilisation du 
stereotype Utility. 



« Utility » 
Math 



PI :Real = 3,14 



sinus(Angle) : Real 
cosinus(Angle) : Real 
tangente(Angle) : Real 
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Exercice 3 Nom d'une classe 



La classe Livre est definie dans le paquetage Ressource se trouvant lui-meme dans le paque- 
tage Bibliotheque. Parmi les attributs de la classe Livre figurent le nom de type String se 
trouvant dans le paquetage Base et Femprunteur de type Adherent se trouvant dans le 
paquetage Bibliotheque. Donnez la representation graphique de la classe Livre. 



Solution 



Quand une classe est definie dans un paquetage, celui-ci peut etre precise dans la declaration 
du nom de la classe. Du point de vue implementation, le paquetage correspond souvent au 
chemin d'acces a la classe. 



Figure 2.41 

Espace de nommage 
des classes. 



bibliotheque: :ressource :: Livre 



emprunteur:Bibbliotheque :: Adherent 
nom :base ::String 



Exercice 4 Definition d'un message asynchrone 



Lors de Fenvoi d'un e-mail, on souhaite lui associer un signal permettant de savoir que le 
message envoye est approuve par le destinataire. Utilisez le mecanisme de classe stereo- 
typee pour modeliser ce message. 



Figure 2.42 

Moderation 
d'un signal. 



Les messages echanges entre les instances de classe sont modelises par des operations. Les 
operations sont, par definition, synchrones. UML 2 a prevu un mecanisme pour Fechange 
des donnees asynchrones. II s'agit des signaux. 

Un signal est un message asynchrone. Comme une operation, le signal possede un nom et 
des parametres. Cependant, un signal peut se modeliser comme une operation, une classe 
ou une interface, en fonction de sa complexity et de sa nature. Quand il est modelise comme 
une operation, il est precede du mot-cle signal. Quand il est modelise par une classe, le nom 
de la classe est precede du stereotype signal. 

On suppose que le signal associe a Fe-mail a une valeur booleenne qui indique si le message 
est approuve ou pas. 



« signal » 
estAllume 



fait : Boolean 



Ce signal aurait pu etre modelise dans 
la classe message sous forme d'un message 
asynchrone comme suit : 
signal estOk():Boolean 
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Chapitre 



EXERCICE 5 CLASSE ACTIVE 



Enonce 



Votre telephone mobile dispose d'un gestionnaire d'evenements qui permet de suspendre 
l'activite du telephone lorsque celui-ci n'est pas sollicite, d'afficher un message quand un 
rendez-vous est programme. Proposez une modelisation UML de ce gestionnaire d'evene- 
ments. 



Solution 



Figure 2.43 

Exemple de classe 
active. 



Le gestionnaire d'evenements peut etre modelise par une classe. L'instance de cette classe 
cree elle-meme des instances de la classe evenements et controle certaines activites de votre 
telephone. II s'agit d'une classe particuliere qualifiee d'« active » par UML. 

Une classe active initie et controle le flux d' activites alors qu'une classe passive (par defaut) 
sauvegarde les donnees et offre les services aux autres. Graphiquement, une classe active est 
representee comme une classe standard, avec une epaisseur de trait plus prononcee. 

Le gestionnaire d'evenements contient des evenements. II est capable de creer un evene- 
ment, de le suspendre, de l'afficher ou de le detruire. Cela donne le modele presente a la 
figure 2.43. 



GestionnaireEvenements 



evts : Evenement[l..n] 



+creation(Evenement) 
+destruction(Evenement) 
+afficher(Evenement) 
+suspendre(Evenement) 



L'epaisseur du trait indique |^^», 
qu'il s'agit d'une classe active. 



EXERCICE 6 CONTRAINTE SUR UNE CLASSE 



Enonce 



Les cartes de visite contiennent diverses informations. Leur caracteristique commune est 
que leurs proprietes sont immuables durant toute la vie de la carte. Proposez une modeli- 
sation UML de cet element. 



Solution 



Vous pouvez geler une association en utilisant la contrainte standard {frozen}. Cette 
contrainte precise que la valeur de l'association est gelee durant toute la vie de l'asso- 
ciation. Ce principe s'applique de la meme maniere pour les classes et les attributs. Dans 
le cas de la classe, cela signifie que les valeurs sont affectees lors de la creation de l'objet et 
ne changent pas. 

Dans le cas de la carte de visite, deux types de contraintes s'accumulent. En effet, la carte de 
visite est en lecture seule et, en principe, une fois imprimee, ses proprietes restent immuables 
durant toute la vie de la carte. Dans le cas general, les deux contraintes sont independantes. 



Figure 2.44 

Ajout des contraintes 
dans la description 
d'une classe. 



CarteDe Visite { frozen, ReadOnly ) 
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Exercice 7 Classe parametrable 



La gestion d'une liste, independamment des objets quelle contient, utilise les operations 
d'ajout, de suppression et de recherche. Proposez une modelisation UML de concept. 



Solution 



Certains langages de programmation a typage fort, comme le C++, utilisent des classes 
parametrables (patrons). L'interet principal est de regrouper les comportements associes a 
la structure de la classe independamment des objets quelle contient. II appartient, par la 
suite, au programmeur de preciser le type d'objet concerne pour que toutes les operations 
soient applicables. 

Modelisez la classe Liste comme une classe standard, en ajoutant a cette definition un ou 
plusieurs parametres substituables ClasseCiblel . . .ClasseCiblen qui representent les classes 
des objets cibles. La figure 2.45 donne la representation graphique de la classe parametrable 
Liste et un exemple de classe cible utilisant cette classe parametrable. Une fois que la classe 
Livre est definie, les operations permettant d'inserer, d'enlever, de chercher un livre s'appli- 
quent automatiquement. 



Figure 2.45 

En utilisant la classe 
parametrable Liste 
et la classe standard 
Livre, on definit une 
liste de livres utilisant 
les proprietes de 
la classe Liste. 



Liste 



-l ClasseCiblel 



+inserer(ClasseCible) 
+ supprimer(ClasseCible) 
+chercher(ClasseCible) 



Livre 



Liste<Livre> 



(1) 



Exercice 8 Relations simples 



Enonce 



Donnez les diagrammes de classes correspondant aux situations suivantes : 

1. Les personnes qui sont associees a l'universite sont des etudiants ou des professeurs. 

2. Un rectangle est caracterise par quatre sommets. Un sommet est un point. On construit 
un rectangle a partir des coordonnees de quatre sommets. II est possible de calculer sa 
surface et son perimetre et de le translates 

3. Un ecrivain possede au moins une oeuvre. Ses oeuvres sont ordonnees selon l'annee de 
publication. Si la premiere publication est faite avant l'age de dix ans, l'ecrivain est dit 
« precoce ». 

4. Tous les jours, le facteur distribue le courrier aux habitants de sa zone d' affectation. 
Quand il s'agit de lettres, il les depose dans les boites aux lettres. Quand il s'agit d'un 
colis, le destinataire du courrier doit signer un recu. Proposez les classes candidates et 
deduisez-en le diagramme de classes. 



Solution 



1. Cet exercice met en evidence l'association multiple entre deux classes et la necessite 
d'ajouter une contrainte (mecanisme d'extension d'UML) pour exprimer le fait que le 
role d'une personne a l'universite est etudiant ou bien professeur. Seuls les noms des 
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Figure 2.46 

Contraintes entre 
associations. 



deux classes, des deux associations et la contrainte entre associations apparaissent dans la 
solution. En effet, vu les informations disponibles dans l'enonce et l'objectif de la mode- 
lisation (mettre en evidence les relations entre classes), il est inutile d'ajouter d'autres 
informations. 





etudier 


Personne 


Universite 


1 

{ou} 




ensetener 





2. II s'agit de representer a la fois les details d'une classe et ses liens avec une autre classe. La 
classe principale a modeliser est la classe Rectangle. Elle est associee a la classe Point qui 
joue le role de « cote » dans l'association avec la classe Rectangle. En Fabsence d'informa- 
tions complementaires permettant, en particulier, de savoir Futilite de modeliser la classe 
Point, vous pouvez proposer deux solutions, Fune faisant apparaitre uniquement la 
classe Rectangle, et Fautre, plus detaillee, faisant apparaitre les classes Rectangle et Point. 

Cela dit, si seule la classe Rectangle est representee, vous perdez Finformation sur l'asso- 
ciation du point vers le rectangle. Cela correspond a une modelisation d'une association 
unidirectionnelle de Rectangle vers Point alors que cette information n'est pas disponible 
directement dans l'enonce. Ce choix peut etre justifie par l'objectif de la modelisation et 
par le choix de l'implementation (pour l'implementation de l'association, un attribut 
point sera ajoute dans Rectangle). 



Figure 2.47 

La figure de gauche 
transforme 
l'association entre 
les classes Rectangle 
et Point en une 
relation de 
composition. 



Rectangle 



-sommet : Point[2] 



« constructor » 
Rectangle(Point, Point) 

« query » 
+ surface () : Float 

« update » 
+translater (Point) 



Rectangle 


* 




« constructor » 
Rectangle(Point, Point) 


- sommel | Point 1 


« query » 




2 1 1 


+ surface () : Float 






« update » 






+translater (Point) 







3. Les deux classes principales sont Ecrivain et (Euvre. Une association bidirectionnelle 
nommee posseder relie les deux classes. Les ceuvres sont ordonnees selon la date de publi- 
cation. Ajoutez done Fattribut datePublication de type Date dans (Buvre et la contrainte 
{ordered} du langage OCL. Celle-ci signifie que les ceuvres sont ordonnees. Pour indi- 
quer que Fecrivain est precoce, ajoutez un commentaire en langage naturel sous forme de 
note. Cette note peut preciser egalement le critere utilise pour Fordonnancement. II est 
aussi necessaire d'ajouter deux attributs dans la classe Ecrivain : dateDeNaissance de type 
Date et /precoce de type Boolean. L'attribut /precoce est un attribut derivee de l'association 
entre ecrivain et ceuvre. Par ailleurs, la multiplicite du cote de Fecrivain n'est pas precisee 
car celle-ci n'est pas indiquee dans l'enonce. 



Figure 2.48 

Ajout de contraintes 
pour limiter la 
portee d'une 
association. 



Si datePublication - dateNaissance 
<10 Fecrivain est dit precoce 



Ecrivain 



#dateNaissance : Date 



{ordered) 1..* 



CEuvre 



#datePublication : Date 
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4. La lecture du texte permet de selectionner les classes candidates suivantes : Facteur, Cour- 
rier, Habitant, ZoneDAffectation, Lettre, BoiteAuxLettres, Colis, Destinataire. 

La redaction d'une liste de classes candidates intervient en phase d'analyse preliminaire. 
Lobjectif est de degager les principaux concepts a partir de l'analyse fonctionnelle. Les 
phases d'analyse et de conception permettent de selectionner les classes qui appa- 
raitront dans le diagramme de classes. Pour trouver les candidates, il faut recourir a un 
expert du domaine, consulter le cahier des charges du client et parfois tenir compte du 
langage d'implementation qui sera utilise pour la realisation (notamment pour les classes 
utilitaires). 

Si la modelisation concerne la mise en evidence du lien entre le facteur et les habitants 
ainsi que la zone d'affectation du facteur, vous pouvez proposer la solution qui suit : 

• La classe BoiteAuxLettres n'est pas pertinente. Elle ne fera pas partie du diagramme de 
classes. 

• Un colis et une lettre sont des courriers particuliers. 

• Le destinataire est le role d'un habitant quand il recoit un courrier. II ne sera pas repre- 
sente par une classe. 

• Un facteur dessert une zone d'affectation qui abrite plusieurs habitants. 

• Le seul lien entre le facteur et l'habitant est la distribution du courrier (classe-association). 



Figure 2.49 

Modelisation d'une 
classe-association. 



Habitant 



Lettre 



destinataire 



Colis 




Courrier 



Facteur 




ZoneDAffectation 



Exercice 9 Realisation d'une interface 



Les etudiants peuvent etre compares par rapport a l'attribut moyenne generale et les livres 
sont comparables par rapport a leurs prix de vente. Pour des raisons d'homogeneite des 
interfaces presentees par les classes, tous les objets comparables utilisent la meme operation 
compareTo(Instance). Proposez le diagramme de classes mettant en evidence l'operation de 
comparaison. 



Les classes qui interviennent dans cette application sont Etudiant et Livre. L'operation com- 
pareTo (Instance) compare tout type d'objet. Elle est done abstraite. Si elle est commune a 
toutes les classes, vous devez la defmir dans une interface que vous appellerez par exemple 
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Comparable. Cette interface sera realisee par les classes qui l'utilisent. Pour l'application 
considered, vous obtenez le diagramme presente a la figure 2.50. 



Figure 2.50 

Realisation 
d'une interface. 



Etudiant 



moyenneGen :float 



« realize > 



« interface » 
Comparable 



.CompareTo(...) 



Livre 



« realize » 



Exercice 1 0 Utilisation d'une interface 



Enonce 



Luniversite propose des cours de langue accessibles aux agents administratifs et aux 
enseignants. La procedure d'inscription est la meme pour les deux categories de personnes. 
Une personne inscrite peut egalement resilier son inscription. Modelisez les classes pour 
representer cette situation. Simplifiez la modelisation en faisant apparaitre uniquement les 
classes Enseignant et AgentAdministratif. 



Solution 



Les agents administratifs et les enseignants sont des personnes particulieres. lis partagent les 
operations inscrireQ et resilierQ, qui font partie de la meme interface : Inscription. Dans un 
premier temps, creez les classes Personne, Enseignant, AgentAdministratif, et Finterface Ins- 
cription qui contient deux operations : inscrireQ et resilierQ. Faites volontairement abstrac- 
tion de la classe Cours car l'objectif ici est de mettre en evidence les relations de dependance 
et de realisation. 

La realisation de Finterface Inscription est faite de la meme maniere par les deux classes deri- 
vees de Personne. De ce fait, et pour eviter la redondance de la realisation, il suffit qu'une seule 
des deux classes s'en charge (relation de realisation) et que la deuxieme utilise les methodes 
obtenues (relation de dependance stereotypee par « use »), comme le montre la figure 2.51. 



Figure 2.51 

La classe Enseignant 
realise I'interface 
Inscription et la classe 
AgentAdministratif 
utilise le resultat. 



Personne 



I 











Ensei 


gnant 




AgentAdministratif 



« interface » 
Inscription 



+inscrire() 
+resilier() 



« use » 



Pour mettre en evidence uniquement les deux classes Enseignant et AgentAdministratif, 
utilisez le lien simplifie de la figure 2.52, qui indique que la classe Enseignant implemente 
Finterface Inscription utilisee par la classe AgentAdministratif. 



Figure 2.52 

Utilisation 
d'une interface. 



Enseignant 



-ex- 



AgentAdministratif 
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Exercice 1 1 Relations 



Une commande est liee a plusieurs produits. A chaque produit de la commande sont asso- 
ciees des dates. 

1. Donnez une modelisation UML de l'association entre ces trois classes. 

Plus precisement, deux dates sont affectees a chaque produit d'une commande, une 
date et un produit sont associes a une seule commande et, a une commande et une date 
donnee sont lies deux a dix produits. 

2. Completez la modelisation UML de l'application. 

Soit la base de donnees suivante : (commande, produit, date) = {(cl,pl,dl), (cl,p2,d2), 
(c2,pl,d2), (c2,p4,d4)}. 

3. Verifiez quelle respecte bien le diagramme UML de la question 1. Sinon, ajoutez-lui les 
tuples necessaires pour la rendre conforme. 



Trois classes peuvent etre extraites de la description de l'application : Commande-, Produit 
et Date. Les deux relations entre les classes definies dans l'enonce sont les suivantes : 

Une relation binaire intervient entre Produit et Commande. La commande est composee 
de plusieurs produits. Mais, les durees de vie des objets ne sont pas liees. De ce fait, cette 
relation peut etre modelisee par une agregation. La commande est composee de plusieurs 
produits. En principe, il faut defmir une multiplicite *. 

Une relation ternaire met en jeu les trois classes Commande, Date et Produit. 



Figure 2.53 
Relation ternaire. 




2 

Date 



2. Pour defmir la multiplicite a mettre a cote d'une classe dans une relation n-aire, calculez 
le nombre d' objets de ladite classe consistant avec chaque ensemble de (n-1) objets des 
autres classes. L' union de ces nombres calcules constitue la cardinality de la relation. Pour 
cette application, calculez le nombre d'objets de la classe Date consistant avec chaque 
couple d'objets des classes Commande et Produit, le nombre d'objets de la classe Com- 
mande consistant avec chaque couple des classes Produit et Date et le nombre d'objets de 
la classe Produit consistant avec chaque couple d'objets des classes Commande et Date. 
Par exemple, l'enonce indique qua chaque couple d'objets des classes Commande et 
Produit sont associees exactement deux dates (figure 2.54). 
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Par ailleurs, meme si l'enonce ne le dit pas explicitement, vous savez qu'une commande 
n'a de sens que si elle porte sur au moins un produit et qu'un produit peut apparaitre 
dans plusieurs commandes. La multiplicite de l'agregation est, de ce fait, restreinte. 



Figure 2.54 

Multiplicity 
associees aux 
relations n-aires. 




3. La contrainte de cardinality est violee plusieurs fois par la base de donnees. Par exemple, 
il est indique qua chaque couple d'instances des classes Commande et Produit corres- 
pondent exactement deux instances de la classe Date. Les couples (c2,pl) et (c2,p4) ne 
verifient pas cette contrainte. 



Commande 


Produit 


Date 
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dl 
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Exercice 12 Heritage 



1. Le chat et le chien sont des animaux. Les animaux possedent tous un nom. Proposez 
une modelisation de cette situation en faisant apparaitre que d'autres animaux que les 
chats et les chiens existent et qu'un animal ne peut pas etre a la fois un chat et un chien. 

2. Les animaux, en fonction de leur categorie (chat, chien...), ont un cri specifique. Si la 
categorie de Fanimal n'est pas connue, le cri ne peut etre realise. Completez la modeli- 
sation precedente pour inclure cette propriete. 

3. Tous les animaux sont comparables par rapport a la puissance, en decibels, du cri 
degage. La valeur maximale est connue pour chaque categorie d'animaux. De plus, 
pour des soucis d'homogeneite, toutes les comparaisons doivent respecter une interface 
commune. Completez le modele precedent avec ces nouvelles informations. 
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Solution 



Vous avez besoin de trois classes : Chat, Chien et Animal. La classe Animal est plus gene- 
rale (heritage) que les deux classes Chien et Chat. Une instance de la classe Chat (respec- 
tivement Chien) ne peut pas etre instance de la classe Chien (respectivement Chat) : il 
s'agit d'un heritage exclusif (utilisation de la contrainte {disjoint} du langage OCL). Par 
ailleurs, d'autres animaux que les chats et les chiens existent. La contrainte {incomplete} 
du langage OCL permet d'exprimer cette contrainte. 



Figure 2.55 

Heritage avec 
contraintes. [.'heritage 
est incomplet et les 
heritiers sont tous 
disjoints. 



Animal 



nom : String 











Chat 




Chien 



•{incomplete, disjoint} 



2. L'operation crier Q est partagee par tous les animaux. Elle doit done apparaitre au niveau 
de la classe Animal. Cependant, la methode associee n'est connue qu'au niveau des 
descendants de cette classe. Cette methode est done abstraite. Les classes Chat et Chien 
doivent absolument redefinir la methode crier (). 



Figure 2.56 

Ajout de la methode 
abstraite partagee 
par tous les heritiers 
de la classe Animal. 



Animal (abstract) 



nom : String 



abstract crier() 



Chat 



Chien 



{incomplete, disjoint) 



Figure 2.57 

Implementation 
de I'interface 
Comparable par 
les classes derivees 
de la classe Animal. 



La valeur en decibels de la puissance des cris est pareille pour chaque categorie d'ani- 
maux . Utilisez done une variable statique. Pour operer les comparaisons, definissez une 
interface commune, par exemple Comparable, contenant les operations necessaires, en 
Foccurrence float compare To (type) qui est realisee par chaque categorie d' animaux comme 
le montre la figure 2.57. 



« interface » 
Comparable 



float compareTo(type) ^ 



« use » • 



: realize » 



Animal {abstract} 



nom : String 



S 

< realize » 



abstract crierQ 



-{ incomplete,disjoint) 



Chat 




Chien 


static float ebitCri 




static float debitCri 
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Exercice 13 Heritage 



Enonce 



Un etudiant et un enseignant sont des personnes particulieres. 

1. Proposez un modele de classes correspondant. 

Un doctorant est un etudiant qui assure des enseignements. La modelisation sera suivie 
par une implementation en Java ou en C++. 

2. Completez le modele de classes precedent en exploitant au mieux les possibilites du lan- 
gage cible. 

Un doctorant et un etudiant doivent s'inscrire au debut de l'annee et eventuellement 
modifier leur inscription. En fonction des deux modeles proposes. 

3. Ajoutez cette fonctionnalite aux deux precedents modeles. 



Solution 



1. Les etudiants et les enseignants heritent de la classe Personne. D'autres personnes, qui 
ne sont ni des etudiants, ni des enseignants, derivent de la classe Personne. Ajoutez la 
contrainte{incomplete} du langage OCL pour expliciter cette situation. 



Figure 2.58 
Relation d'heritage. 



Personne 



Etudiant 



| { incomplete } 



Enseignant 



Un doctorant est a la fois un etudiant et un enseignant. Le doctorant herite a la fois des 
proprietes des enseignants et de celles des etudiants. II s'agit bien d'un heritage multiple. 
Cela necessite, egalement, l'ajout de la contrainte {overlapping}, qui indique qu'un etu- 
diant et un enseignant peuvent instancier le meme objet (l'intersection entre les ensem- 
bles d'objets des classes Enseignant et Etudiant n'est pas vide). Ce modele est correct pour 
une implementation en C++, car ce langage autorise l'heritage multiple. 



Figure 2.59 

Solution en utilisant 
l'heritage multiple. 



Personne 



E 







— 1— 


Etudiant 




Enseignant 



{incomplete, overlapping} 



Fr— 7f 

_ Doctorant _ 



Java n'accepte que l'heritage simple. Cette contrainte implique une modelisation hierar- 
chique de l'heritage. En d'autres termes, une classe peut avoir au plus un seul parent. 
L'ajout de cette contrainte implique implicitement l'ajout de la contrainte {disjoint} entre 
les classes qui derivent directement de toute classe du modele. Vous pouvez modeliser 
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cela en separant les instances des doctorants de celles des etudiants et des enseignants. 
Vous obtenez le modele presente a la figure 2.60. 



Figure 2.60 

Solution en utilisant 
I'heritage simple 



Personne 



J. 



Etudiant 




Enseignant 




Doctorant 



3. L'inscription necessite au moins deux operations. 

Dans le cas de I'heritage simple, la solution consiste a definir une interface Inscription 
contenant les deux operations. Celles-ci peuvent etre realisees par la classe Etudiant et 
utilisees par la classe Doctorant (figure 2.61). 



Figure 2.61 

Solution dans le cas 
de I'heritage simple. 



Personne 



J 








— 1~ 


incomplete, disjoint) 


Etudiant 
\ 




Enseignant 




Doctorant 
s 





« realize » 



« interface » 
Inscription 



La solution proposee par la figure 2.61 est aussi valable dans le cas oil le langage supporte 
I'heritage multiple. Cependant, dans ce dernier cas, deux autres solutions sont possibles 
comme le montre la figure 2.62. 



Figure 2.62 

Les deux solutions 
possibles dans le 
cas de I'heritage 
multiple. 



Personne 



T. 



- - — — — — Ij — {i ncomplete, 
Etudiant | | Enseignant overlapping 



I 



Doctorant 




1 

, 1> 

« realize » 


« interface » 
Inscription 


inscrire() ; 
modifierO ; 



Personne 



Etudiant 



inscrire() ; 
modifierO 



I 



Enseignant 



{ incomplete, 
overlapping 



Doctorant 
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EXERCICE 1 4 DlAGRAMME D'OBJETS 



Enonce 



Un robot se deplace dans un environnement compose de zones, de murs et de portes. 
Proposez le diagramme d'objets decrivant la situation suivante : le robot Mars est en mou- 
vement. II est lie a une instance mondeCourant de la classe Monde decrivant les mondes 
possibles ou peut evoluer le robot. Le robot peut manipuler des objets se trouvant dans le 
monde dans lequel il evolue. 

A l'instant qui nous interesse, le robot Mars est en mouvement et mondeCourant est lie 
aux zones zl et z2. La zone z2 est composee de deux murs (ml et m2) et d'une porte. La 
largeur de la porte est de un metre. 

Donnez le diagramme d'objets associe a cette situation. 



Solution 



Vous avez besoin des classes Robot, Monde, Objet, Zone, Mur et Porte. La classe Robot est 
active. Le diagramme d'objets presente a la figure 2.63 correspond a un snapshot d'une 
situation particuliere et varie selon la position du robot. 



Figure 2.63 
Diagramme d'objets. 



mars:Robot 
[enMouvement] 



mondeCourant : Monde 



lObjet 



z2:Zone 




mliMur 



: Porte 



lareeur:integer= 1 m 



zl:Zone 






m2:Mur 









Exercice 1 5 Patron de conception « objets composites » 



Enonce 



Une figure geometrique est composee de figures simples ou composees. Une figure com- 
posee est constitute de plusieurs figures et une figure simple peut etre un point, une ligne 
ou un cercle. Une figure peut etre dessinee ou translated. 

1. Donnez la modelisation des classes de cette situation. 

2. De maniere plus generate, la notion d'objets composites se retrouve dans beaucoup 
d' applications. De ce fait, il est interessant de proposer un patron de conception qui 
modelise les objets composites et de les instancier en fonction des objets considered. 

Etendez la solution precedente arm de modeliser n'importe quel ensemble d'objets 
decrits par une hierarchie d'agregation d'objets ayant le meme comportement. 



Solution 



1. Toutes les figures comportent les operations dessiner() et translater(). Les methodes 
associees ne sont pas connues, done la classe Figure est abstraite. Une figure peut etre 
specialised en figure simple ou en figure composee. Cette derniere peut etre composee 
(relation d'agregation) de plusieurs figures. 
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Figure 2.64 

Diagramme de 
classes modelisant 
les figures simples 
et composees. 



FigureSimple 



+dessiner( ) 
+translater() 



Figure {abstract} 



+dessiner() 
+translater() 



Element de 




FigureComposee 



+dessiner( ) 
+translater() 



Cercle 


Point 


Ligne 








+dessiner() 
+translater() 


+dessiner() 
+translater() 


+dessiner() 
+translater() 



2. Le patron de conception d'objets composites permet de representer des objets qui se 
decrivent par une hierarchie d'agregation d'objets dans laquelle tous les objets, jusqu'au 
plus haut niveau, presentent un meme comportement (on peut leur appliquer un meme 
ensemble de methodes). Cette solution est proposee par Erich Gamma. 



Figure 2.65 

Le diagramme de 
classes modelisant 
le patron de 
conception « objets 
composites ». 



Les operations communes 
dont certaines sont abstraites. 
Composant{ abstract) 



Composant { abstract } 



■¥operation 



fits de 



Feuille 



+operation() 



Appliquer 1' operation 
a tous les descendants 



Composite 



+operation() 
+ajout(c :Composant) 



Exercice 1 6 Application hoteliere 



Un hotel est compose d'au moins deux chambres. Chaque chambre dispose d'une salle 
d'eau qui peut etre une douche ou une salle de bain. L'hotel heberge des personnes. II peut 
employer du personnel et est dirige par un des employes. L'hotel a les caracteristiques sui- 
vantes : une adresse, le nombre de pieces, la categorie. Une chambre est caracterisee par le 
nombre et le type de lits, le prix et le numero. On peut calculer le chiffre d'affaires, le loyer 
en fonction des occupants. 

1. Donnez le diagramme de classes. 

2. Utilisez les contraintes pour affmer les relations. 
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Solution 



La figure 2.66 propose une solution qui repond aux deux questions. 



Figure 2.66 

Diagramme de 
classes representor)! 
I'application 
hoteliere. 



Hotel 



adresse : String 
categorie : String 



ailculChiffreAffaires( ) : double 



dirige 
1 



heberge 
■ -foul 



emploie 
'ou}_ 



0..1 

{element del 



Personne 



Chambre 



nombreLit : int 
typeLit : String 
lePrix : double 
numero : int 




Loyer(...) : double 



SalleDEau 



douche 



Le loyer est calcule[^^ 
en fonction du nombie 
„ de personnes, de la 
saison, etc. 



Baignoire 



Exercice 1 7 Application bancaire 



Enonce 



Une banque compte plusieurs agences reparties sur le territoire francais. Une banque est 
caracterisee parle nom de son directeur general, son capital global, son propre nom et de 
Fadresse de son siege social. Le directeur general est identifie par son nom, son prenom et 
son revenu. 

Une agence a un numero d'agence et une adresse. Chaque agence emploie plusieurs 
employes, qui se caracterisent par leurs nom, prenom et date d'embauche. Les employes 
peuvent demander leur mutation d'une agence a une autre, mais un employe ne peut tra- 
vailler que dans une seule agence. Les employes d'une agence ne font que gerer des clients. 

Un client ne peut avoir des comptes que dans une seule agence de la banque. Chaque nou- 
veau client se voit systematiquement attribuer un employe de l'agence (conseiller). Les 
clients ont un nom, un prenom et une adresse. 

Les comptes sont de nature differente selon qu'ils soient remuneres ou non (comptes 
courants). Les comptes remuneres ont un taux d'interet et rapportent des interets verses 
annuellement. 

1. Donnez la description complete de toutes les classes (remplissez tous les compartiments). 
Precisez les types des attributs et les types de retour des fonctions. Les attributs sont 
tous prives. Chaque attribut possede deux methodes publiques (getAttribut renvoie la 
valeur d'un attribut et setAttribut affecte une nouvelle valeur a un attribut). Toutes les 
autres methodes sont accessibles uniquement dans le package de la classe. 

2. Analysez les classes trouvees en (1) et modelisez-les en factorisant (par generalisation 
ou autre) au mieux la description des proprietes. 

3. Une relation particuliere lie l'agence, le client, F employe et le compte. De quelle relation 
s'agit-il ? Dessinez le modele de cette relation. 

4. Donnez le diagramme de classes en n'utilisant que leur nom et ajoutez tous les orne- 
ments possibles aux relations. 
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Solution 



Figure 2.67 

Description detaillee 
des classes de 
I'application. 



Les classes qui apparaissent dans cette application sont Banque, Directeur, Agence, 
Employe, Client, CompteRemunere, CompteNonRemunere. 



CompteNonRemunere 



solde : float 
numero : hit 



Agence 



nomAgence :String 
adresseAgence : String 



Banque 


Directeur 


Employe 


-nomDirecteur : String 
-capital : int 
-adresseSiege : String 


-nom : String 
-prenom : String 
-revenu : float 


-nom : String 
-prenom : String 
-dateEmbauche : Date 


+getNomDirecteur() : String 
+setNomDirecteur( String n) 
+getCapital():int 
+setCapital(int capital) 
+getAdresseSiege():String 
+setAdresseSiege( String s) 
Banque(String Adresse) 


+getNom() : String 
+setNom (String n) 
+getPrenom ():String 
+setPrenom (String p) 
+getRevenu(): float 
-t-setRevenu (float s) 


+getNom: String 
+setNom(String n) 
+getPrenom():String 
+setPrenom( String s) 
+getDate(): Date 
+setDate(Date s) 
mutation(Agence g): boolean 





-t-getNomAgenceQ : String 
+setNomAgence(String n) 



C o mpteRemunere 



solde : float 
numero : int 
taux : float 



verserlnteretQ : void 



Client 



-nom : String 
-prenom : String 
-adresse : String 
-conseiller : Employer 
-agence : Agence 
-comptes : [1..NJ Compte 



+getNom: String 
+setNom (String n) 
-l-getPrenom() : String 
-r-setPrenom( String s) 
+getDate(): Date 
+setDate(Dates) 
mutation(Agence g):boolean 



Figure 2.68 

Les liens de 
generalisation 
entre les classes 
de I'application. 



Compte 



1 



Personne 



Directeur 











CompteRemunere 




CompteNonRemunere 



Employe 



Client 
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Figure 2.70 

Diagramme 
de classes de 
1'application 
bancaire. 












CompteRemunere 




CompteNonRemunere 



Exercice 1 8 Reservation de billets d'avion 



Enonce 



Un avion assure plusieurs vols et un vol est assure par un seul avion. Un vol peut etre un 
vol cargo ou un vol de passagers. Les avions utilises pour ces deux types de vols ne sont pas 
les memes. 

1. Donnez le diagramme de classes exprimant cette situation. 

2. Ajoutez les contraintes du langage OCL pour exprimer le fait qu'un vol cargo soit assure 
par un avion-cargo et qu'un vol de passagers soit assure par un avion de passagers. 

Les vols sont proposes par des compagnies aeriennes. Pour un meilleur remplissage des 
avions, un vol est partage par plusieurs affreteurs. Un des affreteurs assure Fouverture et 
la fermeture de chaque vol. Un vol est caracterise par une date et un lieu de depart, une 
date et un lieu d'arrivee. 

3. Donnez la modelisation des classes de cette situation. 

Quand un client fait une reservation aupres d'une compagnie aerienne pour un ou plu- 
sieurs passagers, il est informe du fait que le vol compte plusieurs escales. Une escale est 
caracterisee par des dates d'arrivee et de depart ainsi qu'un aeroport qui dessert plu- 
sieurs villes. 

4. Proposez le diagramme de classes pour cette situation. 

5. A partir de ces diagrammes partiels, proposez un diagramme de classes modelisant cette 
application. 



1. Tous les avions assurent plusieurs vols. II est done utile de remonter l'association "assurer 
vol" au niveau des classes Avion et Vol. Cependant, si vous n'utilisez pas les contraintes et 
si la contrainte specifiant qu'un avion-cargo (respectivement de passagers) assure exclu- 
sivement des vols cargos (respectivement de passagers) alors la seule solution consiste, 
non pas a remonter l'association entre Avion et Vol, mais a la preciser entre tous les types 
de vols et d'avions (figure 2.71). 
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Figure 2.71 
Diagramme 
de classes. 



Avion 



I 



Vol 



I 



AvionCargo 



VolCargo 



AvionPassagers 



VolPassagers 



2. L'ajout des contraintes du langage OCL permet une meilleure generalisation a travers 
l'expression de cas particuliers et d'exceptions. Vous pouvez remonter l'association entre 
un avion et un vol au niveau des classes Vol et Avion et ajouter une contrainte qui res- 
treint l'impact de l'association sur les instances des classes (figure 2.71). 



Figure 2.72 

Generalisation de 
l'association assure 
par l'ajout de 
contraintes OCL. 



Avion 


* 


assurer 


1 


Vol 


1 



i 



context Vol 
inv: type=cargo implies Avion. type=cargo 
inv: type=passager implies Avion. type=passager 



AvionCargo 



VolCargo 



AvionPassagers 



VolPassagers 



3. Le role de la compagnie aerienne par rapport a un vol est celui d'affreteur. L'affreteur qui 
ouvre un vol est aussi celui qui le ferme. De plus, un vol ne peut etre ouvert puis ferme 
qu'une seule fois. UML ne fournit pas un moyen d'exprimer cette double synchronisa- 
tion. De ce fait, une note est ajoutee au diagramme pour exprimer cette contrainte. Les 
caracteristiques d'un vol (dates et lieux) ne sont pas detaillees et seront representees par 
de simples attributs. 



Figure 2.73 

Modelisation 
detaillee de 
la classe Vol. 



Vol 



#dateDepart : Date 
#date Arri vee : Date 
#lieuDepart:Lieu 
#lieuArri vee : Lieu 



+ouvrirVol() 
+fermerVol() 



I.. 



propose 



CompagnieAerienne 



Preconditions D-- 1 *! 
ouvrir(): instance de vol jamais ouverte 
former(): instance de vol ouverte par le 
meme objet et jamais fermee. 



4. L'association qui lie le client et la compagnie aerienne concerne la reservation. La reser- 
vation nait de cette association et se compose de toutes les donnees la concernant. II s'agit 
done d'une classe-association. La reservation concerne un passager et un vol. 

Dans la modelisation precedente, les lieux de depart et d'arrivee ne sont pas detailles 
(representation sous forme d' attributs). Cette fois, le lieu est connu : il s'agit de l'aero- 
port. Les deux attributs modelisant le lieu se transforment en role dans les associations 
reliant le vol et l'aeroport. 
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Figure 2.74 

Moderation des 
vols des compagnies 



aenennes. 



Une escale se caracterise par des dates et un aeroport. Elle est decrite par les attributs de 
la classe Vol mais pas par ses methodes (ouvrirQ, fermer ()...). Ce n'est done pas un vol 
particulier. Un vol peut compter plusieurs escales ordonnees. Chaque escale est liee a un 
aeroport. L'escale nait d'une relation entre un vol et un aeroport, qui n'est ni un aeroport 
de depart, ni un aeroport d'arrivee. Les escales sont representees par une classe-association 
entre un vol et un aeroport. 



Client 




Vol 


depart 

* 1 
arnvee 


Aeroport 








* 1 
{ordered) 





CompagnieAerienne 



Passager 



Escale 



dateDepart:Date 
date Arrivee : Date 



Ville 



Exercice 1 9 Patron « Bridge » 



Enonce 



Une figure geometrique peut etre un cercle ou rectangle. On souhaite proposer aux clients 
un outil de dessin des figures geometriques qui s'adapte a l'environnement informatique. 
Les interfaces, la qualite des dessins dependent de l'environnement. 

1 .Proposez une modelisation qui isole le dessin d'une figure geometrique et qui la specia- 
lise en fonction de l'environnement. 

2. Selon le meme principe et d'une maniere plus generale, on souhaite concevoir une 
structure qui permet a un client de voir une classe et ses operations de haut niveau. 
Cette structure doit separer completement la definition abstraite des classes et leur 
implementation. 

Proposez un schema de modelisation. 



Solution 



1. Le client est associe aux figures geometriques. Son objectif est de les dessiner. La figure 
geometrique est composee d'un ensemble de proprietes, dont celles liees au dessin (trait, 
couleur, etc.). Ces proprietes dependent de l'environnement (elles sont specialisees). La 
figure geometrique peut etre specialisee, en particulier, en cercle ou en rectangle. 



Figure 2.75 

Modelisation 

Senerique d'une 
gure geometrique. 




FigureGeometrique ^ 



Dessin 











Cercle 




Rectangle 



I 











Dessinlnterface 1 




Dessinlnterface2 
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Figure 2.76 

Diagramme de 
classes du patron 
de conception 
« Bridge ». 



L'abstraction est visible par les clients, renvoie les demandes vers l'implementation {ope- 
ration=Implementation. operation) et fournit des fonctions de haut niveau. Les classes 
RefinedAbstraction implementent les differentes abstractions, a la facon des classes Figu- 
reGeometrique qui implementent differentes figures. Implementation est une interface 
entre plusieurs implementations possibles. Elle offre des operations de bas niveau. Les 
classes Implementation 1 et Implementation! permettent d'implementer l'interface Imple- 
mentation en proposant des methodes concretes. 




+Implementation.operations() 



Abstraction 



+operation() ^ 



1 



y 

y 

> 


Implementation 


+operation() 













RefinedAbstraction 




RefinedAbstraction 



1 











Implementation! 




Implementation2 



Exercice 20 Patron « Adapteur » 



Un editeur de jeux possede un jeu permettant aux enfants de connaitre les animaux. Les 
enfants peuvent, en particulier, apprendre la forme et le cri des animaux parmi lesquels le 
chat et la vache. Le chat est modelise par la classe LeChat possedant au moins les deux 
methodes formeChat() et criChatQ et la vache est modelisee par la classe LaVache posse- 
dant les deux methodes criVache() etformeVache(). 

Comme le montrent les noms des methodes, la premiere specification de ce jeu est propre 
aux animaux modelises. L'editeur souhaite ameliorer ce jeu en creant une interface com- 
mune a tous les animaux qui lui permette d'en ajouter de nouveaux, sans modifier l'inter- 
face avec le client, et d'utiliser le polymorphisme dans la gestion des animaux (manipuler 
des troupeaux...). 

1. Proposez une modelisation des classes pour cette nouvelle version du jeu en faisant 
apparaitre le client. 

2 .On souhaite reutiliser tout le code developpe dans la version precedente. Proposez une 
modelisation permettant d'incorporer les anciennes methodes pour eviter de les 
recrire. 

3. Est-il possible de generaliser ce raisonnement pour les applications de meme type ? Si 
c'est le cas, proposez le patron generique correspondant. 



1. Chaque animal est modelise par une classe : Chat, Vache, etc. Ces classes possedent au 
moins les comportements suivants : crier () etforme(). Les methodes implementees dans 
les differentes classes d'animaux ont toutes les memes operations (memes signatures de 
methodes). Cela signifie que le client qui utilise un animal n'a pas besoin de savoir a 
priori de quel animal il s'agit exactement ; il doit pouvoir acceder a un ensemble d'opera- 
tions. En ce sens, il suffit de creer une classe generale appelee Animal, qui regroupe les 
operations communes. Cela permet de traiter tous les animaux de la meme maniere, sans 
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se soucier des differences d'implementation, et d'ajouter ulterieurement de nouveaux 
animaux sans devoir modifier le client. 



Figure 277 

Generalisation 
des proprietes des 
animaux dans la 
classe Animal, seule 
interface avec le 
client. 







Animal (abstract) 


Client 




> 


+crier():{abstract) 






+forme():{ abstract} 




2. 



Figure 2.78 

La classe LeChat 
existante et la 
nouvelle classe Chat. 



Figure 2.79 

Les classes Chat et 
Vache encapsulent 
respectivement les 
classes LeChat et 
LaVache. 



L'ajout d'une classe d'animaux quelconques doit se faire par derivation de la classe Ani- 
mal. Cette nouvelle classe doit absolument implementer les methodes abstraites de la 
classe Animal. 

Pour pouvoir reutiliser les methodes deja developpees et garder la propriete du polymor- 
phisme, vous devez trouver un moyen d'adapter les noms des anciennes methodes aux 
noms generiques choisis dans la nouvelle version du jeu. Par exemple, pour le cas de la 
classe Chat, il suffit de trouver un moyen d'appeler les methodes criChatQ etformeChat() 
de la classe LeChat. La solution simple qui permet de resoudre ce probleme consiste a 
mettre la classe LeChat dans la classe Chat. La composition permet la delegation d'opera- 
tions. Ainsi, la classe Chat se contente tout simplement de deleguer les operations qu'on 
lui demande a la classe LeChat et d'utiliser par la meme le code deja developpe. 





Chat 


La methode crier() se £^ 
contentera d' appeler la methode 
criChatQ de la classe LeChat 




+crier() 
+forme() 









LeChat 


i 

1 1 


+criChat() 
+formeChat() 



Ce processus d'encapsulation des classes de Fancienne version est decrit a la figure 2.78. 







Animal j abstract ) 


Client 




> 


+crier() 






+ formeQ 



I 



Chat 



+crier() 
+forme() 



I 



Vache 



+crier() 
+forme() 



LeChat 



+criChat() 
+formeChat() 



Lion 



+crier() 
+forme() 



LaVache 



+criVache() 
+formeVache() 



3. 



Ce mecanisme d'adaptation par encapsulation peut etre utile dans le contexte d'utilisa- 
tion du polymorphisme. II permet aussi de ne plus se poser de questions sur l'integration 
de classes existantes lors de la phase de conception : la solution presentee ici ne presente 
aucune contrainte et peut etre utilisee facilement. II s'agit d'une instance du patron 
« Adaptateur ». 
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La solution generique du patron « Adaptateur » consiste done a faire correspondre a une 
interface donnee un objet existant contenant des methodes quelconques. En simplinant 
la figure 2.79, vous obtenez la solution generique presentee a la figure 2.80. 



Figure 2.80 

Vue simplifiee 

du patron 

« Adaptateur ». 



Client 


S 


ClasseCible 


< 


Adaptateur 




ClasseAdaptee 




+methode() 





+methode() 


♦ 


+methodeAdaptee() 




+methode(){ 







instanceClasseAdaptee.methodeAdaptee() ; 



Exercice 2 1 Organisation du langage UML 



Enonce 



La specification du langage UML 2 defmit un type de donnees comme un classeur parti- 
culier dans le paquetage Noyau. Un type de donnees est compose de plusieurs proprietes et 
de plusieurs operations ordonnees. Un type primitif, comme les entiers, et un type enumere 
sont deux specialisations d'un type de donnees. Un type enumere est compose de litteraux 
ordonnes. Utilisez cette description et vos connaissances de la modelisation des types en 
UML pour proposer le modele de classes des types de donnees. 



Solution 



Cette solution est extraite de la norme UML 2.0 superstructure specification publiee par 
TOMG. 



Figure 2.81 

Diagramme de 
classes d'un type 
de donnees dans 
le metamodele UML 



Classifier 



DataType 



PrimitiveType 



+datatype 



+ownedAttribute 



0..1 {subsets namespace, 
subsets featuringClassifier, 
subsets classifier} 

+datatype 



{ordered, 
subsets attribute, 
subsets owned Member} 

+ownedOperation 



0..1 {subsets namespace, 
subsets redefinitionContext, 
subsets featuringClassifier} 



{ordered, 
subsets feature, 
subsets ownedMember} 



Enumeration 



+enumeration 



+ownedl_iteral 



0..1 {subset namespace} {ordered, 

subsets ownedMember} 
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Operation 



InstanceSpecification 
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d / interaction 




1 . Interet des interactions 

2. Diagramme de sequence 
en detail 

3. Diagramme de communication 

en detail 101 

4. Reutilisation d'une interaction 104 

Problemes et exercices 

1. Syntaxe des messages 107 

2. Ajouter un aspect dynamique 
d un diagramme de classes 
et traduction d'un diagramme 
de sequence en diagramme 

de communication 1 09 

3. Messages synchrones vs messages 
asynchrones Ill 

4. Messages perdus, trouves ou 
envoyes dans des flots d'execution 
paralleles 114 

5. Fragments d'interaction combines 
pour decrire une methode 
complexe 115 

6. Operateurs d'interaction 116 

7. Diagrammes de sequence 

pour illustrer des cas d'utilisation .. 117 

8. Fragments d'interaction combines . 1 20 

9. Diagrammes de sequence 

pour illustrer des collaborations .... 1 21 

1 0. Reutilisation d'une interaction 1 24 

1 1 . Diagrammes de sequence 
pour illustrer les interactions 

dans un classeur structure 1 25 



Le diagramme de cas d'utilisation montre des acteurs qui 
interagissent avec les grandes fonctions d'un systeme. 
C'est une vision fonctionnelle et externe d'un systeme. 
Le diagramme de classes, quant d lui, decrit le cceur d'un 
systeme et montre des classes et la facon dont elles sont 
associees. C'est une vision statique et structurelle. 
Les diagrammes d'interaction permettent d'etablir un pont 
entre ces deux approches : ils montrent comment des 
instances au cceur du systeme communiquent pour realiser 
une certaine fonctionnalite. Les interactions sont nombreuses 
et variees. Il faut un langage riche pour les exprimer. 
UML propose plusieurs diagrammes : diagramme de 
sequence, diagramme de communication, diagramme de 
timing. Ils apportent un aspect dynamique a la modelisation 
du systeme. 
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□ Interet des interactions 



Les diagrammes de cas d'utilisation montrent des interactions entre des acteurs et les gran- 
des fonctions d'un systeme. Cependant, les interactions ne se limitent pas aux acteurs : par 
exemple, des objets au coeur d'un systeme, instances de classes, interagissent lorsqu'ils 
s'echangent des messages. 



EXEMPLE Le diagramme de classes presente a la figure 3.1 montre la structure interne d'un systeme de 

pilotage automatique compose des trois classes : PiloteAutomatique, Voiture et Moteur. Ce 
diagramme n'indique pas comment le pilotage est realise. Pour ajouter un aspect dynamique 
a la modelisation, il faut « descendre » au niveau des instances et montrer comment elles 
interagissent. 

Des instances de ces classes peuvent figurer sur un diagramme d'interaction particulier, 
appele « diagramme de communication » (figure 3.2). Dans cet exemple, les instances 
s'envoient les messages demarrer et allumer. Pratiquement, I'envoi des messages declenche 
I'appel des methodes demarrer et allumer, ce qui a pour effet de consulter ou de changer 
I'etat de la voiture et du moteur respectivement. 

Plus generalement, une interaction montre le comportement d'un classeur tel qu'un sous-systeme, 
un cas d'utilisation, une classe, un composant, etc. 

Figure 3.1 

Diagramme de 
classes d'un systeme 
de pilotage 
automatique. 

Figure 3.2 

Diagramme de 
communication d'un 
systeme de pilotage 
automatique. 



PiloteAutomatique 




Voiture 




Moteur 
















demarrerO 




allumer() 



com Piloter 



unPilote : PiloteAutomatique 



demarrer 



une Voiture : Voiture 



allumer 



leMoteur : Moteur 



Definition 

Une interaction decrit le comportement d'un classeur en se focalisant sur I'echange d'infor- 
mations entre les elements du classeur. Les participants a une interaction sont appeles 
« lignes de vie ». 

Une ligne de vie represente un participant unique d une interaction. 



Le terme « ligne de vie » est utilise car, souvent, les interactions montrent des objets (ins- 
tances de classes). Au cours d'une interaction, des objets peuvent etre crees, utilises, et 
parfois detruits. Ce cycle de vie des objets est materialise par une ligne (la ligne de vie) qui 
court dans les diagrammes d'interaction (figure 3.3). 

UML propose principalement deux diagrammes pour illustrer une interaction : le diagramme 
de sequence et celui de communication. Une meme interaction peut etre representee aussi 
bien par l'un que par l'autre. 
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EXEMPLE 



Le diagramme de sequence de la figure 3.3 et le diagramme de communication de la figure 
3.2 represented la meme interaction. 



Figure 3.3 

Un diagramme de 
sequence a la place 
d'un diagramme 
de communication. 



sd Piloter 



J 



unPilote : PiloteAutomatique 
1 



uneVoiture : Voiture 



"T~ 



leMoteur : Moteur 



"T 



sens du 
temps 



demarrer 



allumer 



ligne de vie 



Diagrammes de sequence et de communication peuvent representer la meme interaction, 
mais le point de vue est different. Un diagramme de sequence met l'accent sur le sequence- 
ment temporel des messages (le temps y figure implicitement et s'ecoule de haut en bas) ; en 
revanche, le lien qui unit les lignes de vie, et qui est le vecteur du message, n'y figure pas 
(alors qu'il est present sur un diagramme de communication). 



Definition 




Les diagrammes de communication et de sequence represented des interactions entre des 
lignes de vie. Un diagramme de sequence montre des interactions sous un angle temporel, 
et plus particulierement le sequencement temporel de messages echanges entre des lignes 
de vie, tandis qu'un diagramme de communication montre une representation spatiale des 
lignes de vie. 



Remarque 

Aux diagrammes de sequence et de communication s'ajoute un troisieme type de dia- 
gramme d'interaction : le diagramme de timing. Son usage est limite a la moderation des 
systemes qui s'executent sous de fortes contraintes de temps, comme les systemes temps 
reel. Cependant, meme dans ces situations extremes, les diagrammes de sequence con- 
viennent bien souvent. C'est la raison pour laquelle les diagrammes de timing ne sont pas 
abordes dans cet ouvrage. Le lecteur interesse trouvera dans le manuel de reference d'UML 
2.0 [Rumbaugh 2004] des explications sur le sujet. 



Notation 

Un diagramme d'interaction se represente par un rectangle (figure 3.4) contenant, dans 
le coin superieur gauche, un pentagone accompagne du mot-cle sd lorsqu'il s'agit d'un 
diagramme de sequence, et de com lorsqu'il s'agit d'un diagramme de communication. 
Le mot-cle est suivi du nom de I'interaction. La liste des lignes de vie qui figurent dans le 
diagramme peut suivre le nom de I'interaction. Des attributs peuvent etre indiques pres du 
sommet du rectangle contenant le diagramme. La syntaxe de ces attributs est la meme que 
celle des attributs d'une classe (voir chapitre 2). 

Une ligne de vie se represente par un rectangle auquel est accrochee une ligne verticale 
pointillee. Le rectangle contient un identifiant dont la syntaxe est la suivante : 

[<nomDeLaLigneDeVie> [ 1 [ 1 selecteur 1 ] 1 ] ] : <NomDeClasseur> [decomposition] 

ou le selecteur permet de choisir un objet parmi n (par exemple objet[2] ). 
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Figure 3.4 



Contrainte sur la 
valeur de l'attribut 



Un diagramme 
de sequence d'un 
distributeur de billets. 



Attribut de 1' interaction 



Ligne de vie 



sd Retrait argent lifelines :Client, : Distributeur, :Banque 





+code : integer { readonly 1000 <= code <= 9999 j 



: Distributeur 



comBanque : Reseau 



Client 



introduireCarte 



afficherEcranSaisieCode 



saisieCode( code ) 



verifierCode( code ) 



banqueOK = verifierCode( _ ) 



1 . 1 Utilisation des interactions 



Les diagrammes d'interaction sont utilises tout au long du cycle de vie d'un projet (depuis 
le recueil des besoins jusqu'a la phase de conception). lis servent a decrire les cas d' utilisa- 
tion dans les phases en amont, a modeliser la mise en oeuvre d'une classe ou d'une operation 
d'une classe et, plus generalement, a ajouter un aspect dynamique a la modelisation d'un 
systeme. 

Le diagramme de classes modelise avant tout le domaine dans lequel le systeme sera utilise ; 
ce domaine, celui d'une banque par exemple, est relativement independant des applications 
bancaires qui viennent se greffer dessus ; l'implementation d'un diagramme de classes n'est 
qu'une base de developpement pour des applications ; ce qui caracterise une application, 
c'est la facon dont elle utilise le diagramme de classes, ou plus precisement, comment des 
instances des classes interagissent pour realiser les fonctionnalites de l'application ; sans cet 
aspect dynamique, un systeme serait purement statique et n'offrirait aucune fonctionnalite. 

L'approche objet du developpement d'un systeme recommande une conception modulaire 
(de sorte que les parties du systeme soient reutilisables). Le langage de modelisation doit 
permettre la representation de cette modularity. II n'est pas souhaitable de faire figurer tou- 
tes les interactions sur un seul diagramme. Le modelisateur doit pouvoir focaliser son atten- 
tion sur un sous-ensemble d'elements du systeme et etudier leur facon d'interagir pour 
donner un comportement particulier au systeme. UML permet de decrire un comporte- 
ment limite a un contexte precis de deux facons : dans le cadre d'un classeur structure ou 
dans celui d'une collaboration. 

Interactions dans les classeurs structures 

La structure imbriquee d'un classeur structure limite les interactions possibles entre ses par- 
ties, chacune d'elles ne pouvant appartenir a un autre classeur structure (voir l'annexe B 
pour de plus amples informations). 



UML 2 



Chapitre 



EXEMPLE 



Considerons une classe qui est decomposee pour montrer sa structure interne (figure 3.5) : 
une classe Mofeur est composee des classes Allumage et Bougie. Un diagramme de sequence 
montre comment les bougies et I'allumage interagissent pour demarrer le moteur. 



Figure 3.5 

Un diagramme 
de sequence 
pour illustrer le 
comportement 
interne d'une classe. 



interaction 

boucle pour 
allumer les 
bougies 



structure interne 
de la classe 



Moteur 



sd allumer moteur 



: Allumage 
1 



bougie [ i ] : Bougies 
1 



loopCM),! j 


allumer i 




] "P 

1 



: Allumage 




: Bougies 


1..4 



Les classeurs structures sont surtout utilises dans la phase de conception d'un systeme, 
quand on determine la facon dont il va etre realise. Le concepteur prend pour point de 
depart les classeurs mis en evidence au moment de l'analyse ; il decide de leur structure 
interne et illustre eventuellement leur comportement par des interactions. Les classeurs 
ainsi structures sont repris par les developpeurs qui implementent une solution. 

Interactions dans le cadre d'une collaboration 

Les parties de la structure interne d'un classeur structure sont creees des que le classeur est 
instancie. Leur duree de vie est celle de l'instance du classeur. Parfois, des instances existent 
avant d'etre utilisees. Elles peuvent etre reunies temporairement, le temps de collaborer a la 
realisation d'une certaine fonctionnalite d'un systeme. Une fois leur role joue, leur tache 
s'acheve et la reunion est dissoute. Certaines instances devenues obsoletes sont detruites, 
d'autres liberees jusqu'a leur prochaine utilisation. Ce type de reunion d'instances est une 
collaboration. 



Definition 

Une collaboration montre des instances qui collaborent dans un contexte donne pour met- 
tre en oeuvre une fonctionnalite d'un systeme. 



EXEMPLE La figure 3.6 montre une collaboration entre instances pour realiser une transaction immo- 

biliere. 



Notation 




Une collaboration se represente par une ellipse en trait pointille comprenant deux compar- 
timents. Le compartiment superieur contient le nom de la collaboration ayant pour syntaxe : 
<nomDuR61e>[ 1 : ' <NomDuType>] [multiplicite] 
Le compartiment inferieur montre les participants d la collaboration. 
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Diagramme 
de collaboration 
d'une transaction 
immobiliere. 



ventelmmobiliere 



acquereur : Personne 



contratVente : Transaction 



proprietaire : Personne 



notaire : Notaire 



connecteur 



Comme dans les classeurs structures, des connecteurs relient les instances d'une collabora- 
tion. Un connecteur represente souvent une association transitoire (etablie le temps que 
dure la collaboration - concretement, ce peut etre l'argument d'une methode, une variable 
locale, une association. . . ). 



Notation 

Une collaboration peut aussi se representer par une ellipse sans compartiment, portant le 
nom de la collaboration en son sein (figure 3.7). Les instances sont reliees a I'ellipse par 
des lignes qui portent le nom du role de chaque instance. 



Figure 3.7 

Representation 
possible d'une 
collaboration. 
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Les interactions au sein d'une collaboration peuvent etre representees par un diagramme 
d'interaction comme le montre la figure 3.8. 



Figure 3.8 

Un diagramme 
de sequence 
pour illustrer 
une collaboration. 



sd ventelmmobiliere 



7 



notaire : Notaire 



contratVente : Transaction 



proprietaire : Personne 



acquereur : Personne 



etablir 



signer 



signer 
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0 Diagramme de sequence en detail 



Chapitre 



Les principales informations contenues dans un diagramme de sequence sont les messages 
echanges entre les lignes de vie. Un message definit une communication particuliere entre 
des lignes de vie. Plusieurs types de messages existent. 

Les plus communs sont : 

• l'envoi d'un signal ; 

• l'invocation d'une operation ; 

• la creation ou la destruction d'une instance. 

L'envoi d'un signal declenche une reaction chez le recepteur, de facon asynchrone et sans 
reponse : l'emetteur du signal ne reste pas bloque le temps que le signal parvienne au recep- 
teur et il ne sait pas quand, ni meme si le message sera traite par le destinataire. Un exemple 
typique de signal est une interruption (lorsque des donnees sont saisies au clavier d'un ordi- 
nateur par exemple, le processeur recoit un signal electrique d'interruption lui donnant 
l'ordre de lire les donnees du clavier, mais la lecture ne bloque pas le clavier). 

Plus encore que l'envoi d'un signal, l'invocation d'une operation est le type de message le 
plus utilise en programmation objet. Si, par exemple, une classe C possede une operation 
op, l'invocation se fait par c.op(), ou c est une instance de la classe C. L'invocation peut etre 
synchrone (l'emetteur reste bloque le temps que dure l'invocation de l'operation) ou asyn- 
chrone. Dans la pratique, la plupart des invocations sont synchrones. Une des techniques 
utilisees pour realiser une invocation asynchrone consiste a creer un thread (un thread est 
un flot d' execution parallele) et a executer la methode associee a l'operation dans ce thread. 

Pour UML, l'envoi d'un signal ou l'invocation d'une operation sont deux sortes de messages 
qui se representent de la meme facon. Par contre, UML fait la difference entre un message 
synchrone et un message asynchrone. 



Notation 

Un message synchrone se represente par une fleche d I'extremite pleine qui pointe sur le 
destinataire du message (figure 3.9). Ce message peut etre suivi d'une reponse qui se 
represente par une fleche en pointille. 

Un message asynchrone se represente par une fleche d I'extremite ouverte (figure 3.10). 
La creation d'un objet est materialisee par une fleche qui pointe sur le sommet d'une ligne 
de vie (figure 3.1 1 ). 

La destruction d'un objet est materialisee par une croix qui marque la fin de la ligne de vie 
de I'objet (figure 3.1 2). 



► 

et 3.10 

Representation d'un message synchrone (3.9) et d'un message asynchrone (3.10). 



Figures 3.11 

et3.12 

Representation de la creation (3.1 1) et destruction (3.12). 



nouvelObjet : Classe 



I 
I 

X 



L'emetteur d'un message asynchrone n'etant pas bloque le temps que le message parvienne 
au recepteur, une serie de messages peut etre envoyee avant qu'un seul ne soit recu. De plus, 
les messages peuvent etre recus dans un ordre different de l'ordre d'envoi. 
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EXEMPLE La figure 3.1 3 montre une communication sur un reseau d'ordinateurs (certains protocoles de 

communication tel UDP ne garantissent pas I'ordre d'arrivee des messages). 

Figure 3.1 3 

Messages asynchrones 
recus dans un ordre 
different de I'ordre 
d'envoi. 



sd communication sur un reseau d'ordinateurs 



7 



: Serveur 




2.1 Message et evenements 



L'invocation d'une operation ou l'envoi d'un signal peut declencher une reaction chez le 
recepteur. La reaction la plus courante est l'execution d'une methode (rappel : une methode 
est l'implementation d'une operation). Ce n'est cependant pas la seule reaction possible. Par 
exemple, un signal d'erreur (souvent appele « exception ») peut etre interprets comme une 
simple alerte qui ne declenchera pas necessairement l'execution d'une methode. Meme 
dans le cas de l'invocation d'une operation, il n'est pas evident que l'invocation soit suivie 
de l'execution d'une methode : dans les middlewares a objets qui forment aujourd'hui 
l'ossature des systemes d'informations des entreprises, des objets sont repartis sur un reseau 
d'ordinateurs ; l'invocation se fait done a distance et des erreurs de transmission peuvent 
empecher le message d'invocation d'arriver au recepteur. 

UML permet de separer clairement l'envoi du message de sa reception, ainsi que le debut de 
l'execution de la reaction de sa fin. Des evenements sont utilises pour marquer chaque etape. 
Ainsi, la transmission d'un message est controlee par l'occurrence de deux evenements : un 
pour l'envoi et un pour la reception. 



Exemple 



Figure 3.14 

Diagramme 
de sequence 
ou figurent, 

Eour explication, 
(s occurrences 
d'evenement. 



La figure 3.14 montre un diagramme d'interaction ou un message envoye provoque l'execu- 
tion d'une methode chez le recepteur. 



Evenement d'envoi 



sd Retrait argent 



7 



: Distributeur 



Client 



introduireCarte 



Evenement de 
reception 



Evenement de 
debut d'execution 



Evenement de fin 
d'execution 
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Chapitre 



Notation 



La specification de I'execution d'une reaction se fait par un rectangle blanc ou gris place 
sur la ligne de vie (figure 3.14). Autre notation : un rectangle portant un label. 



EXEMPLE 

Figure 3.1 5 

Autre specification 
d'une execution. 



La figure 3.15 specifie differemment I'execution de la reaction decrite a la figure 3.14. 



Evenement 
d' envoi 



sd Retrait argent 



: Distributeur 



Evenement 
de reception 
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verifierCarte 



Evenement de 
debut d' execution 



Evenement de fin 
d' execution 



Grace aux evenements d'envoi et de reception, UML definit trois types de messages : 

• Un message complet est tel que les evenements d'envoi et de reception sont connus. 

• Un message perdu est tel que l'evenement d'envoi est connu, mais pas l'evenement de 
reception. 

• Un message trouve est tel que l'evenement de reception est connu, mais pas l'evenement 
d'emission. 

Ces differents messages se representent de la facon suivante. 

Notation 

Un message complet se represente par une simple fleche dirigee de I'emetteur vers le recep- 
teur. Un message perdu se represente par une fleche qui pointe sur une boule noire (figure 
3.16). Une fleche qui part d'une boule noire symbolise un message trouve (figure 3.17). 



Figure 3.1 6 

Representation d'un 
message perdu. 

Figure 3.1 7 

Representation d'un 
message trouve. 
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2.2 Syntaxe des messages 



UML permet de modeliser tout type de systeme. Mais bien souvent, les implementations se 
font via des langages de programmation. Dans la plupart des cas, la reception d'un message 
est suivie de 1' execution d'une methode d'une classe. Cette methode peut recevoir des argu- 
ments et la syntaxe des messages permet de transmettre ces arguments. 

Notation 

La syntaxe des messages est : 

<nomDuSignalOuDeOperation> ['(' [<argument> 1 , 1 ... ')'] 
ou la syntaxe des arguments est la suivante : 

[ <nomDeParametre> '=' ] <valeur de l'argument> 

Par defaut, les parametres transmis ne peuvent pas etre modifies par le recepteur (les argu- 
ments sont « en entree »). Pour indiquer que des parametres peuvent etre modifies (argument 
« en sortie » ou « en entree/sortie »), il faut ecrire : 

<nomDuParametreEnSortie> [':' <valeur de l'argument> ] 

Quand un message doit transmettre uniquement la valeur des arguments, le caractere - peut 
etre utilise en lieu et place de n'importe quel argument pour signiner : valeur indefinie. Le 
caractere * peut etre utilise en lieu et place du message complet. II signifie que tout type de 
message est accepte. 



EXEMPLE Appeler( "Capitaine Hadock", 54214110 ) 

afficher( x, y ) 

initialiser^ x = 100 ) est un message dont 1' argument en entree regoit la 
valeur 100. 

f( x :12 ) est un message avec un argument en entree/sortie x qui prend 
initialement la valeur 12. 
appeler( "Castaf iore" , - ) 

Le recepteur du message peut aussi vouloir repondre et transmettre un resultat via un 
message de retour. 



Notation 




La syntaxe de reponse d un message est la suivante : 




[<attribut> 1=1 ] message [':' <valeur de retour> ] 




ou message represente le message d'envoi. 





EXEMPLE La figure 3.1 8 montre un message de reponse signalant que quarante-deux occurrences de la 

reference « Tintin » figurent dans une mediatheque. 
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Figure 3.1 8 

Exemple d'un 
message de 
reponse. 




Chapitre 



Contrainte sur les valeurs d'un attribut 



sd Rechercher livre 



ivrej 



+nombreLivres : integer { nombreLivres >= 0 ' 



: Mediatheque 



Client 



chercher( "Tintin" ) 



nombreLivres = chercher( "Tintin" ) : 42 
;< 



2.3 CONTRAINTES SUR LES LIGNES DE VIE 



La figure 3.18 contient un attribut, nombreLivres, auquel est accolee une contrainte qui 
limite les valeurs possibles du nombre de livres. Les lignes de vie d'une interaction peuvent 
aussi porter toutes sortes de contraintes. Si la ligne de vie est un objet par exemple, une 
contrainte sur la valeur d'un attribut peut etre posee. 



Exemple 



Figure 3.1 9 

Exemple d'une 
contrainte sur 
une ligne de vie. 



La figure 3.19 montre que, pour demarrer le moteur d'un avion, il est imperatif de verifier le 
niveau d'essence ; apres verification I'attribut essence doit avoir une valeur superieure a 0. 



sd Piloter Avion 



7 



: Pilote 



: Avion 



Operateur d'assertion qui rend 
indispensable l'envoi du message 
verifierEssence (voir le paragraphe 
ci-dessous sur les fragments combines) 



demarrerMoteurQ 



assert 



7 



J verifierEssence() 
{ Avion.essence > 0 } 




Notation 



Une contrainte est indiquee sur une ligne de vie par un texte entre accolades. 
Une contrainte peut aussi etre contenue dans une note attachee d I'occurrence de I'eve- 
nement sur lequel elle agit. 



Une contrainte est evaluee au cours de l'execution de l'interaction. Si la condition de la 
contrainte n'est pas verifiee, les occurrences d'evenement qui suivent cette contrainte sont 
considerees comme invalides, alors qu'une contrainte qui se verifie rend valides les evene- 
ments a suivre. Ainsi, a la figure 3.19, si la quantite d'essence est nulle, decoller devient un 
message invalide. 
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_ 



Remarque 




Un diagramme d'interaction peut decrire des messages non valides, c'est-d-dire qui ne doi- 
vent absolument pas etre envoyes : dans le cas de la modelisation d'une centrale nucleaire 
par exemple, il est tres important de prevoir les sequences des messages invalides. 



2.4 Fragments d'interaction combines 



Les langages de programmation sont limites par leur syntaxe. Certes, ils permettent 
d'ecrire des tests et des boucles tres simplement. Par contre, ecrire un programme avec des 
flots d'instructions devant s'executer en parallele n'est pas simple (il faut ecrire des instruc- 
tions pour creer, soit des taches, soit des threads, puis utiliser d'autres instructions pour 
synchroniser les flots d'instructions...). UML, sans etre un langage de programmation, 
propose une syntaxe qui se veut complete. Quand le modelisateur doit representor une 
situation complexe, UML permet de decomposer une interaction en fragments suffisam- 
ment simples pour les faire tenir sur un schema. La combinaison des fragments permet 
de reconstituer la complexity du systeme. Le terme generique en vigueur pour UML est 
« fragments combines ». 



Exemple 



La figure 3.20 montre comment representee a I'aide d'UML, I'equivalent du test des langages 
de programmation. 



Figure 3.20 

Representation 
d'un choix dans 
un diagramme 
de sequence. 
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Notation 

Un fragment combine se represente de la meme facon qu'une interaction : par un rectangle 
dont le coin superieur gauche contient un pentagone. Dans le pentagone figure le type de 
la combinaison (appele « operateur d'interaction »). 

A la figure 3.20, l'operateur d'interaction alt indique que le fragment est un choix. Les deux 
options de choix sont appelees « operandes de l'operateur alt ». 
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Notation 

Les operandes d'un operateur d'interaction sont separes par une ligne pointillee. Les condi- 
tions de choix des operandes sont donnees par des expressions booleennes entre crochets. 
La liste suivante regroupe les operateurs d'interaction par fonctions : 

• les operateurs de choix et de boucle : alternative, option, break et loop ; 

• les operateurs controlant I'envoi en parallele de messages : parallel et critical region ; 

• les operateurs controlant I'envoi de messages : ignore, consider, assertion et negative ; 

• les operateurs fixant I'ordre d'envoi des messages : weak sequencing, strict sequencing. 



EXEMPLE 



La figure 3.21 montre comment une boucle peut etre representee. L'exemple illustre la ferme- 
ture en boucle de toutes les portes d'un train. 



Notation 

La syntaxe d'une boucle est la suivante : 

loop [ 1 ( 1 <minint> [ 1 , 1 <maxint> ] 1 ) 1 ] 

ou la boucle est repetee au moins minint fois avant qu'une eventuelle condition booleenne 
ne soit testee (la condition est placee entre crochets sur la ligne de vie) ; tant que la condi- 
tion est vraie, la boucle continue, au plus maxint fois (minint est un entier superieur ou egal 
d 0, maxint est un entier superieur ou egal d minit). 
loop( valeur ) est equivalent d loop( valeur, valeur ). 
loop est equivalent d loop ( 0, * ) , ou * signifie « illimite ». 



Figure 3.21 

Diagramme de 
sequence montrant 
une boucle. 



sd Demarrer train 



7 



: Conducteur 



: Train 



fermerPortes() 



loop(l, n) ~) 



portef i ] : Porte 



fermer() 



L'operateur par permet d'envoyer des messages en parallele. Ses operandes se deroulent en 
parallele. Plus precisement, les evenements qui jalonnent un operande (I'envoi du message, 
la reception du message. . . ) ferment une trace. Soumise a l'operateur par, la trace d'un ope- 
rande est conservee (I'ordre des evenements est le meme), mais les differentes traces des 
differents operandes s'entrelacent n'importe comment. En consequence, la trace finale, 
obtenue par la fusion des traces des operandes, peut varier d'un deroulement a l'autre. La 
figure 3.22 montre un exemple. 
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Figure 3.22 

Utilisation de 
l'operateur par. 



Les operateurs ignore et consider permettent de focaliser l'attention du modelisateur sur une 
partie des messages qui peuvent etre envoyes durant une interaction. Quand de nombreux 
messages sont possibles, certains sont importants, d'autres moins. Le modelisateur peut 
choisir de ne pas tenir compte de tous les messages. Pour un systeme en phase de test par 
exemple, de nombreux messages servent a tester exhaustivement le bon fonctionnement du 
systeme mais ne seront pas emis lors d'une utilisation particuliere (quand le systeme sera en 
production). L'operateur ignore definit l'ensemble des messages a ignorer, tandis que I'ope- 
rateur consider definit l'ensemble de ceux qu'il faut prendre en compte. A la figure 3.23, un 
operateur assert s'applique au message fermer. Ce message doit imperativement etre envoye 
avant que le train puisse demarrer. 



operandes qui 
se deroulent 
en parallele 




Exemple 

Figure 3.23 

Utilisation des 
operateurs ignore, 
consider et assert. 



La figure 3.23 est un exemple d'utilisation des operateurs assert, ignore et consider. 

s d Demarrer train, ignore { testerMoteur ), consider { fermer, demarrer } J 



: Conducteur 



Portes 



Moteur 



assert 



fermer() 



demarrer() 



Notation 

La syntaxe de l'operateur ignore est : 

ignore { listeDesNomsDesMessagesAIgnorer } 
La syntaxe de l'operateur consider est : 

consider { listeDesNomsDesMessagesAConsiderer } 
Dans les listes, les messages sont separes par des virgules. 
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L'operateur strict sequencing impose que ses operandes se deroulent dans l'ordre strict de 
leur presentation, c'est-a-dire de haut en bas. L'ordre impose ne s'applique qua ses operandes, 
et d'eventuels fragments imbriques peuvent avoir, en interne, un sequencement quelconque. 



EXEMPLE La figure 3.24 illustre un scenario de decollage d'un avion qui utilise l'operateur strict sequen- 

cing. Avant de faire decoller un avion, il faut controler sa ckeck-list. Le detail des interactions 
pour controler la check-list et pour faire decoller I'avion n'est pas donne. D'autres diagram- 
mes references sous le label ref s'en chargent. 



Figure 3.24 

Deroulement des 
operandes d'un 
operateur dans 
un ordre strict. 



sd DecoUage d'un avion] 



: TourDeControle 





: Pilote 




: Avion 





Procedure de decollage 



+ 
I 
I 

I 



2.5 Decomposition d'une ligne de vie 



Parfois, une interaction est trop complexe pour etre decrite sur un seul diagramme. UML 
permet de decomposer a volonte une ligne de vie sur plusieurs diagrammes. 



EXEMPLE 



L'exemple suivant modelise un controle d'acces pour entrer dans un batiment. La ligne de vie 
SystemeContrdleAcces a un comportement complexe decrit sur un diagramme separe : Syste- 
meControleAccesUtilisateur (figure 3.26). 



Notation 




Une decomposition est referencee dans le rectangle en tete de ligne de vie, sous le label ref 
[figure 3.25). 

A la figure 3.26, la ligne de vie PointDAcces est decomposee en deux lignes pi et p2. 
Cette notation est une autre maniere de decomposer une ligne de vie dans un diagramme 
d'interaction. 



On remarque a la figure 3.26, la presence d'un message entrant verifier ( code ) et d'un 
message sortant message ( "Entrez !" ); ces messages entrent et sortent du diagramme 
par un point appele « porte ». Ces memes messages sont presents sur le diagramme de la 
figure 3.25. 



Diagramme d'interaction 




Definition 

Une porte est un point de connexion qui permet de relier un mime message represents par 
des fleches differentes dans plusieurs fragments d'interaction. 



Figure 3.25 

Decomposition 
d'une ligne de vie. 



Ligne de vie decomposee 
sur la figure 3.26 



sd verifier acces 



References a des 
diagrammes existants 



7 



+code : integer { 1000 <= code <= 9999 



: Utilisateur 



ref 



: SystemeControleAcces 
ref SystemeControleAccesUtilisateur 



verifier( code ) 



VerifierAcces( code ) 



ref 


> j 


1 

[ code ok ] 

message( "Entrez !" ) | 

1 

1 






ref J 


OuvrirPorte 
1 — 1 






I 
i 


1 




i 1 



Figure 3.26 

Ligne de vie 
decomposee. 



Autre notation 
pour la decomposition 



portes 



opt 



sd SystemeControleAccesUtilisateur 



+PointDAcces.code : integer { 1000 <= code <= 9999 



: PointDAcces 



Pi 

- r - 

verifier( code ) 



P2 



: Controleur 



ref 



SysteraeVerifierAcces( code ) 



7 



[ code ok ] 



message( "Entrez !" ) 
1 1 



opt 



SystemeOuvrirPorte 
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2.6 Les etats invariants 



Chapitre 



Une ligne de vie peut aussi representer un classeur ayant un comportement complexe. C'est 
le cas des instances de classes qui peuvent etre dans plusieurs etats (voir chapitre 4). II est 
possible de placer un certain etat d'une machine a etats sur une ligne de vie. 



Definition 




Un etat est dit « invariant » lorsqu'il reste constant sur une ligne de vie, c'est-d-dire lorsqu'il 
ne change pas quel que soit le contexte d'execution de I'interaction. 



EXEMPLE 



La figure 3.27 montre un etat place sur une ligne de vie. Au moment de I'execution de I'inter- 
action, I'etat est teste conformement d la machine d etats specifiee. 



Figure 3.27 

Ajouter le contrdle 
de I'etat d'une 
ligne de vie dans 
une interaction. 



sd Piloter Avion 



9 



: Avion 



: Pilote 



controlerQ 



AvionPretAuDecollage 



decollerQ 



0 Diagramme de communication en detail 

Un diagramme de sequence montre un sequencement temporel des messages (le temps 
s'ecoule de haut en bas). Par contre, l'organisation spatiale des participants a I'interaction 
n'apparait pas. Un diagramme de communication est un autre moyen de decrire une inter- 
action. II rend compte des relations entre des lignes de vie qui communiquent. II represente 
des interactions du point de vue spatial. Les diagrammes de communication servent le plus 
souvent a illustrer un cas d'utilisation ou a decrire une operation. 
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EXEMPLE 



Le diagramme de la figure 3.28 montre la mise en oeuvre d'une operation (fermerPortes) qui 
permet de fermer toutes les portes d'un train. 



Figure 3.28 

Un diagramme de 
communication pour 
illustrer la fermeture 
des portes d'un 
train. 



com Demarrer train 



fermerPortesQ 



: Train 



1 : fermerLesPortesQ 



1.1 *[i :=l..n] : fermerPorte( i ) 



portes : Portes 



/ 



connecteur 



ligne de vie 



numero de sequence 



iteration nom de role 



nom de classe 



Un diagramme de communication contient des lignes de vie, a l'instar des diagrammes de 
sequence : elles representent toujours des participants uniques a une interaction, mais les 
pointilles qui materialisaient leur duree de vie ont disparu. 

Notation 

Les lignes de vie sont representees par des rectangles contenant une etiquette dont la syntaxe 
est : 

<nomDuR61e> : <NomDuType> 

Au moins un des deux noms doit etre mentionne dans I'etiquette (si le nom du role est omis, 
le caractere : est obligatoire). 



Le role permet de definir le contexte d'utilisation de Finteraction. Si la ligne de vie est un 
objet, celui-ci peut avoir au cours de sa vie plusieurs roles : une instance d'une classe Per- 
sonne peut jouer le role d'un etudiant dans un contexte donne, et devenir le conducteur 
d'une voiture a un autre moment. 

Les diagrammes de communication sont proches des diagrammes de classes auxquels ils 
ajoutent un aspect dynamique en montrant des envois de messages. Cependant, les rela- 
tions entre les lignes de vie sont appelees « connecteurs » alors qu' elles se nomment « asso- 
ciations » dans les diagrammes de classes. Un connecteur se represente de la meme facon 
qu'une association mais la semantique est plus large : les associations qui figurent dans un 
diagramme de classes representent des relations independamment de tout contexte, tandis 
que, pour un systeme en etat de marche, il est possible de connecter ses elements de nom- 
breuses facons : un objet par exemple, peut etre transmis comme un parametre a une 
procedure ou etre une variable locale. 
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Les connecteurs peuvent montrer la multiplicite des lignes de vie qui participent a une 
interaction, comme le montre la figure 3.29. 

Figure 3.29 

Representation de 
la multiplicite dans 
un diagramme de 
communication. 



3.1 NllMEROS DE SEQUENCE DES MESSAGES 



Dans un diagramme de communication, les messages peuvent etre ordonnes selon un 
numero de sequence croissant. Quand plusieurs messages sont envoyes en cascade (par 
exemple quand une procedure appelle une sous-procedure), ils portent un numero 
d'emboitement qui precise leur niveau d'imbrication. A la figure 3.28, le message fermer- 
LesPortes porte le numero 1 et declenche le message fermerPorte qui porte le numero 1.1. 

3.2 Messages et flots d'execution paralleles 



II est possible d'envoyer des messages simultanement dans des flots d'execution qui se 
deroulent en parallele (dans les applications multitaches ou multithreads, plusieurs flots 
d'instructions s'executent en parallele et une meme methode peut etre executee simultane- 
ment dans plusieurs flots). Les flots paralleles sont designes par des lettres (a, b...). 



EXEMPLE La figure 3.30 illustre le parcours d'un arbre binaire : le message visiter est envoye aux deux 

fils (gauche et droit) d'un nceud pere ; ce message est transmis d deux flots paralleles portant 
les lettres a et b. 

Figure 3.30 

Envoi d'un message 
dans des flots 
d'execution 
paralleles. 



com Demarrer train 



7 



fermerPortesO 



: Train 



fermerPorte() 



multiplicite 



porte : Porte 



com Parcourir nceud arbre 



7 



visiter() 



pere : Nceud 



l.a, l.b : visiter() 



fils : Nceud 
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3.3 Operateurs de choix et de boucle 



Les diagrammes de sequence permettent de representer divers operateurs (choix, boucle. . .) 
dans des fragments combines. II n'est pas permis d'utiliser les fragments combines dans un 
diagramme de communication. Malgre tout, des choix et des boucles peuvent y figurer 
selon une syntaxe particuliere. 

Notation 

* [ <clause d'iteration> ] represente une iteration (figure 3.28). La clause d'iteration 
peut etre exprimee dans le format i := 1...n. 

[ <clause de condition> ] represente un choix. La clause de condition est une condition 
booleen ne. 

I I 

3.4 Syntaxe des messages 



Notation 

La syntaxe complete des messages est (voir les exemples ci-apres) : 

[ <numero_sequence> ] [ <expression> ] : <message> 

ou message a la mime forme que dans les diagrammes de sequence, numero_sequence 
represente le numero de sequencement des messages tel qu'il a ete defini precedemment et 
expression precise une iteration ou un embranchement. 



EXEMPLE 2 : affiche( x, y ) est un message simple. 

1.3.1 : trouve( "Hadock" ) est un appel emboTte. 

4 [x < 0] : inverse( x, couleur ) est un message conditionnel. 

3.1 *[i : =1 . .10] : recommencer( ) represente une iteration. 



□ Reutilisation d'une interaction 

Une bonne pratique de l'approche objet consiste a concevoir un systeme en modules qui 
pourront etre extraits de leur contexte initial et reutilises ailleurs. Un langage de modelisa- 
tion doit permettre de prevoir la reutilisabilite. UML propose les diagrammes de compo- 
sants pour decomposer un systeme en modules (voir Fannexe C). A un niveau de details 
plus fin, il est possible de decrire completement une interaction une fois, puis de la reutiliser 
a volonte, en y faisant simplement reference. Les diagrammes de sequence et les diagram- 
mes de communication peuvent etre references. 



EXEMPLE La figure 3.31 montre le travail d'un controleur aerien. Un pilote verifie la check-list de son 

avion (le diagramme correspondent appele controlerCheckList n'est pas decrit en detail mais 
simplement reference). La check-list est transmise en argument car elle est utilisee par Interac- 
tion controlerCheckList. Cette interaction retourne un booleen qui est affecte d I'attribut ok de 
I'avion. Lorsque le controleur demande d controler I'avion, le booleen ok est teste. Si I'avion 
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est pret d partir, son plan de vol est valide ; dans le cas contraire, le plan de vol est invalide. 
['interaction controleAvion (dont le nom figure dans le pentagone en haut d gauche du dia- 
gramme) recoit en argument une instance de Checklist. Cet argument est en entree/sortie 
(inout) car il est utilise dans le diagramme et pourra servir encore dans un autre diagramme 
qui referencera controleAvion. controleAvion retourne un resultat du type PlanDeVol. L'ins- 
tance correspondante est la ligne de vie appelee planDeVol dans le diagramme. 



Figure 3.31 

Utilisation d'une 
interaction avec des 
arguments et une 
valeur de retour. 



Argument en entree Reference une 

/ sortie interaction existante 



Instance du PlanDeVol 
retournee 



sd controleAvion( inout chec klist : CheckList ) : PlanDevol^ ~ 



+Avion.ok : booleen 



: Controleur 



: Pilote 




: Avion 





checklist : CheckList 



controlerCheckList( checklist ) 



planDeVol 




Notation 

Reutiliser une interaction consiste d placer un fragment portant la reference ref Id ou I'inter- 
action est utile. La syntaxe complete pour specifier I'interaction d reutiliser est la suivante : 

[ <nomAttributPourValeurRetour> '='] <nom de 1 ' interaction> 
['(' [<argument>] 1 , 1 ... ')' ] [':' <valeur de retour> ] 

La valeur de retour est affectee d un attribut. Les arguments peuvent etre en entree (ils por- 
tent alors la marque in), en sortie (out), ou en entree et en sortie (inout). 
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Conclusion 



Les diagrammes de sequence et de communication montrent l'aspect dynamique d'un sys- 
teme. Ce ne sont pas les seuls : les diagrammes d'activite et les diagrammes d'etats-transitions, 
presentes aux chapitres suivants, decrivent eux aussi un systeme sous cet angle. Cependant, 
les diagrammes de sequence et de communication sont mieux appropries a la description 
des interactions entre les elements d'un systeme. 

Une interaction montre un comportement typique d'un systeme dans un contexte donne. 
Le contexte est delimite par un classeur structure ou une collaboration. La vision du sys- 
teme donnee par les diagrammes d'interaction est done partielle (car limitee a un contexte 
donne) mais coherente (car elle montre comment un comportement d'un systeme est rea- 
lise par des elements qui le compose). Une interaction peut illustrer un cas d' utilisation, le 
fonctionnement d'un sous-systeme, la mise en oeuvre d'une classe ou d'une operation. Les 
diagrammes d'interaction peuvent etre affines : les interactions decouvertes lors des phases 
en amont du cycle de vie d'un projet peuvent etre completees par les modelisateurs. Chaque 
intervenant n'a pas les memes exigences et n'envisage pas les memes interactions de la 
meme facon. Malgre ces exigences differentes, il est important d'assurer une continuite dans 
la modelisation. Les diagrammes d'interaction peuvent etre completes a mesure que la 
modelisation progresse et portes a un niveau de details requis pour l'implementation du 
systeme. 

Diagrammes de sequence et de communication peuvent decrire une meme interaction mais 
de facons differentes. Le modelisateur a le choix : les diagrammes de sequence montrent le 
sequencement temporel de messages, tandis que les diagrammes de communication decrivent 
la structure spatiale des participants a une interaction. 

Arrive a ce stade de la lecture du livre, et si vous avez parcouru les chapitres precedents dans 
l'ordre, vous savez a present comment construire les trois modeles essentiels d'un systeme : 

• le modele fonctionnel et externe a l'aide du diagramme des cas d'utilisation ; 

• le modele structurel et interne grace au diagramme des classes ; 

• le modele des interactions au sein du systeme avec les diagrammes de sequence et de 
communication. 

A partir de la, vous pouvez passer directement au chapitre 6 pour voir sur une etude de cas 
comment tous ces modeles s'assemblent, ou continuer la lecture des chapitres suivants. 
Deux diagrammes supplementaires y sont presentes : 

• le diagramme d'etats-transitions ; 

• le diagramme d'activites. 

Les diagrammes d'etats-transitions sont utilises avant tout pour decrire le cycle de vie 
des objets d'un systeme : tout objet est forcement cree a un moment donne, utilise via les 
methodes de la classe dont il est issu et, eventuellement, detruit s'il devient inutile. Les dia- 
grammes d'activites sont des organigrammes. lis montrent les flots de controle qui gerent 
les activites d'un systeme. lis permettent de modeliser tout processus sequentiel (un proces- 
sus de fabrication industriel, le fonctionnement d'un systeme d'information, le corps d'une 
operation...). 
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Problemes 
et exercices 

Les diagrammes d' interaction reposent sur la transmission de messages. Avant 
d'utiliser les interactions, il est necessaire de maTtriser la syntaxe des messages, qui 
est riche et complexe. Parmi les premiers exercices, certains sont consacres a la 
syntaxe, d'autres aux differents types de messages (synchrone, asynchrone, perdu, 
trouve...). Plusieurs exercices montrent I'equivalence entre les diagrammes de 
sequence et de communication. Une fois ces notions de base mattrisees, vous 
pourrez realiser les exercices suivants, qui mettent en pratique les diagrammes 
d' interaction. Bien souvent, ces diagrammes sont utilises pour ajouter un aspect 
dynamique au modele du diagramme de classes. Le lien entre diagramme de 
classes et diagramme d'interaction est illustre par des exercices, tout comme les 
autres utilisations des interactions (decrire un cas d'utilisation, une operation, le 
comportement d'un classeur structure ou d'une collaboration). Tout au long des 
exemples, il est fait appel aux fragments d'interaction combines, qui permettent 
d'enrichir les modeles. 



Exercice 1 Syntaxe des messages 



Enonce 



1. Expliquez la syntaxe des messages suivants extraits d'un diagramme de sequence : 



f 

f( 
f( 
f( 
f( 
f( 
f( 



= 0 : 
= x : 
i 

y ) 



y = f 

y = f ( 0 

y = f ( x 

y = f ( x 



0 ) 
: 0 
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2. Expliquez la syntaxe des messages suivants extraits d'un diagramme de communication : 



f 

y := f( x ) 

1 : f 

1 .1 : f 

[x>0] : f 

*[x>0] : f 

*[i :=0. . 10] : f 

1 *[i :=0. . 10] : f 

1 .a *[i :=0. . 10] : f 



1. La plupart des messages portent f comme nom. 
f est un message sans argument. 

f ( 0 ) est un message qui recoit en argument la valeur 0. 

f ( x ) est un message qui recoit la valeur de x en argument. 

f ( x = 0 ) est un message qui recoit un argument x ayant pour valeur 0. 

f ( y = x ) est un message ayant un argument y qui prend la valeur de x. 

f ( - ) est un message avec un argument non defini. 

f ( x , y ) est un message qui recoit en arguments les valeurs de x et de y. 

* est un message de type quelconque. 

y = f est un message de reponse a un message f ; la valeur de retour est affectee a y. 

y = f ( 0 ) est un message de reponse a un message f ( 0 ) ; la valeur de retour est affec- 
tee a y. 

y = f ( x = 0 ) est un message de reponse a un message f( x = 0) ; la valeur de retour est 
affectee a y. 

y = f ( x ) : 0 est un message de reponse a un message f ( x ) ; la valeur de retour 0 est 
affectee a y. 

2. La syntaxe des messages dans les diagrammes de communication est de la forme : 

[<numeroSequence>] [<expression>] : <message> 

ou message a la meme syntaxe et la meme signification que dans les diagrammes de 
sequence. 

f est un message sans argument. 

y : = f ( x ) est un message qui est suivi de F execution chez le recepteur d'une reaction 
(par exemple, l'invocation d'une operation) ; le resultat de la reaction est affecte a y. 

1 : f est un message sans argument qui porte le numero de sequence 1. 

1.1: f est un message emboite sans argument qui porte le numero de sequence 1.1. 

[ x>0 ] : f est un message sans argument qui n'est emis que si la condition x > 0 est vraie. 

*[x>0] : f est un message sans argument qui est emis tant que la condition x > 0 est vraie. 

* [ i : =0 . . 1 0 ] : f est un message sans argument qui est emis onze fois (pour i allant de 
OalO). 

1 * [ i : =0 . . 1 0] : f est un message sans argument, portant le numero de sequence 1, 
qui est emis onze fois (pour i allant de 0 a 10). 

1.a *[i :=0..10] : f est un message sans argument, portant le numero de sequence 1 , 
qui est emis onze fois (pour i allant de 0 a 10) dans un flot d'execution parallele identifie 
par le caractere a. 
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EXERCICE 2 AJOUTER UN ASPECT DYNAMIQUE A UN DIAGRAMME DE CLASSES 
ET TRADUCTION D'UN DIAGRAMME DE SEQUENCE EN DIAGRAMME 
DE COMMUNICATION 



Enonce 



Figure 3.32 

Diagramme 
de classes 
d'un robot. 



Le diagramme de classes presente a la figure 3.32 modelise un robot qui dispose d'un bras 
articule se terminant par une pince. Le fonctionnement du robot est le suivant : le robot 
deplie son bras, attrape la piece avec sa pince, replie son bras puis relache la piece. 



Robot 



chercherPiece 



BrasArticule 



deplier 
replier 



Pince 



ouvnr 
fermer 



Solution 



1. Representez a l'aide d'un diagramme de sequence l'echange des messages entre les 
objets robot, brasArticule et pince. 

2. Transformez le diagramme de sequence en un diagramme de communication. 

3. Ecrivez en pseudo-code les classes Robot, BrasArticule et Pince. 



1. Le diagramme de sequence est presente a la figure 3.33. Le message chercherPiece 
parvient au robot via une porte. L'emetteur du message est suppose apparaitre dans un 
diagramme non represente ici. chercherPiece entraine l'envoi des messages deplier et 
replier au bras articule. Conformement a ce qui est stipule dans le rectangle specifiant 
l'execution de la methode deplier (respectivement replier), le message fermer (respective- 
ment ouvrir) est envoye a la pince. 



Figure 3.33 

Diagramme de 
sequence du robot. 



porte 



sd Attraper piece 



: Robot 



— r 

chercherPiece I 



BrasArticule 



: Pince 



deplier 



replier 





specifications de l'execution des methodes 



2. Le diagramme de communication (figure 3.34) se deduit aisement du diagramme de 
sequence precedent (figure 3.33). II faut cependant veiller a numeroter correctement les 
messages pour indiquer leur ordre d'envoi : le premier message, chercherPiece, porte le 
numero 1 ; le message suivant, deplier, est emboite dans le message chercherPiece et porte 
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en consequence le numero 1.1 ; le message fermer (numero 1.1.1) est emboite dans le 
message deplier. Le meme raisonnement a permis de numeroter les messages replier et 
ouvrir. 



Figure 3.34 

Diagramme de 
communication 
equivalent au 
diagramme de 
sequence de la 
figure 3.33. 



com Attraper piece 



ece^J 



1 : chercherPiece() 



: Robot 



1.1: deplier 



1.2: replier 



: BrasArticule 



1.1.1 : fermer 
1.2.1 : ouvrir 



: Pince 



3. Le pseudo-code montre que l'objet brasArticule est inclus dans la partie des attributs de la 
classe Robot. C'est la facon la plus courante d'implementer une relation de composition : 
le robot est compose d'un bras articule. II en est de meme des classes BrasArticule et 
Pince. 



class Robot{ 
privee : 

BrasArticule brasArticule ; 

publique : 

void chercherPiece ( ) { 

brasArticule. deplier( ) 

brasArticule . replier ( ) 



objet brasArticule (instance 
de la classe BrasArticule) */ 



appel de la methode deplier 
de l'objet brasArticule */ 
appel de la methode replier 
de l'objet brasArticule */ 



class BrasArticule { 
privee : 

Pince pince ; 

publique : 

void deplier (){ 



pince. fermer( ) 



} 

void replier (){ 



pince. ouvrir( ) 



class Pince { 
privee : 



publique : 

void fermer (){ 



/* objet pince (instance de 
la classe Pince) */ 



/* instructions pour deplier 

le bras */ 
/* fermeture de la pince pour 

attraper la piece */ 



/* instructions pour replier 

le bras */ 
/* ouverture de la pince pour 

relacher la piece */ 



/* instructions pour fermer 
la pince */ 
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void ouvrir (){ 
} 

} 

Debut programme principal 
Robot robot ; 

robot . chercherPiece ( ) 

Fin programme principal 



/* instructions pour ouvrir la pince */ 



/* creation d'un objet robot 

(instance de la classe Robot) */ 

/* appel de la methode 

chercherPiece de la classe Robot */ 



Remarque 

Les associations sont souvent implementees comme des attributs. II ne faut cependant pas 
confondre les deux (voir chapitre 2). Malheureusement, de nombreux langages de pro- 
grammation ne permettent pas de faire la distinction. 

L'annexe E donne des indications pour implementer un modele objet avec le langage de 
programmation Java. 



Exercice 3 Messages synchrones vs messages asynchrones 



Enonce 



Completez les messages des figures 3.35 a 3.39 en choisissant le type de message approprie 
(synchrone ou asynchrone). 

1. Envoi d'un message pour calculer la valeur de la constante pi avec 3 decimales. 



Figure 3.35 

Calcul de Pi avec 
3 decimales. 



: ProgrammePrincipal 



: FonctionDeCalculDePi 



Envoi du message 



calculerPI( nombreDecimales = 3 ) 



Message de reponse 



PI = calculerPI( nombreDecimales = 3 ) 



2. Envoi d'un message pour calculer la valeur de pi avec 3 000 decimales. 



Figure 3.36 

Calcul de pi avec 
3 000 decimales. 



: ProgrammePrincipal 



: FonctionDeCalculDePi 



Envoi du message — I calculerPI( nombreDecimales = 3000 ) 

Message de reponse j PI = calculerPI( nombreDecimales = 3000 ) j 

I 
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Enonce (suite) 



Figure 3.37 

Transmission 
d'un courrier 
electronique. 



Figure 3.38 

Transmission 
d'un courrier 
electronique 
via un serveur 
de messagerie. 



3. Transmission d'un courrier electronique. 



: Emetteur 



Destinataire 



transmettre( message ) 



4. Transmission d'un courrier electronique via un serveur de messagerie qui receptionne 
les messages et les conserve le temps que le destinataire les recupere. 



: Emetteur 




ServeurDeMessagerie 



: Destinataire 



poster( message ] 



message = recuperer 



5. Transmission d'un courrier electronique a deux destinataires. 




Transmission d'un 




: Emetteur 




destinataire 1 : Destinataire 




destinataire2 : Destinataire 


courrier a deux 
destinataires. 


1 transmettre( message ) | 












transmettre( message ) 



Solution 



Figure 3.40 

Calcul de Pi avec 
3 decimales utilisant 
un message 
synchrone. 



1. On considere que le programme principal est actif tout le temps. Le calcul de pi avec 
3 decimales ne doit pas prendre beaucoup de temps. Le programme principal peut done 
etre bloque par un appel synchrone de la methode calculerPI le temps d'effectuer le calcul 
(figure 3.40). 

objet actif 



ProgrammePrincipal 



objet actif 



: FonctionDeCalculDePi 



calculerPI( nombreDecimales = 3 ) 



PI = calculerPI( nombreDecimales = 3 ) 



objet passif 
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Remarque 

La tete de la ligne de vie ProgrammePrincipal contient deux traits verticaux qui indiquent 
que I'objet est actif. Le double trait qui court tout au long de la ligne de vie indique aussi un 
objet actif. Ces deux notations presentes simultanement sont redondantes. Dans un dia- 
gramme de sequence, les deux traits verticaux dans la tete de la ligne de vie sont superflus, 
tandis que dans un diagramme de communication, comme aucun pointille n'indique la 
duree de vie d'un objet, ces deux traits sont indispensables (figure 3.48). 
Un objet actif possede son propre thread de controle, c'est-d-dire qu'on peut lui appliquer 
des methodes dans un flot d'execution independant des autres flots d'execution existants. 
Un objet passif, au contraire, a besoin qu'on lui « donne » un flot de controle pour lui appli- 
quer une methode. 



2. Calculer Pi avec 3 000 decimales peut prendre du temps. Dans ce cas, il vaut mieux utili- 
ser un message asynchrone pour ne pas bloquer le programme principal le temps d'effec- 
tuer le calcul (figure 3.41). 



Figure 3.41 

Calcul de Pi avec 
3 000 decimales 
utilisant un message 
asynchrone. 



: ProgrammePrincipal 



FonctionDeCalculDePi 



calculerPI( nombreDecimales = 3000 ) 



PI = calculerPI( nombreDecimales = 3000 ) 



Figure 3.42 

Transmission 
asynchrone 
d'un courrier 
electronique. 



3. La reception d'un courrier electronique peut se faire n'importe quand apres remission. II 
ne faut done pas bloquer l'emetteur et utiliser un message asynchrone (figure 3.42). 



: Emetteur 



: Destinataire 



transmettre( message ) 



4. L'emetteur et le destinataire sont des objets actifs qui sont bloques le temps d'envoyer ou 
de recuperer un courrier (figure 3.43). 



Figure 3.43 

Transmission 
synchrone d'un 
courrier electronique 
via un serveur de 
messagerie. 



: Emetteur 



: ServeurDeMessagerie 



poster( message ) 



T 



Destinataire 



message = recuperet 



5. Les transmissions sont asynchrones et les messages peuvent etre recus dans un ordre 
different de l'ordre d'envoi (figure 3.44). 
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Figure 3.44 

Transmission d'un 
courrier a deux 
destinataires 
via des messages 
asynchrones. 



Destinataire 



transmettre( message ) 



destinataire 1 : Destinataire destinataire2 : Destinataire 



Remarque 

La duree de transmission d'un message peut etre indiquee en ajoutant des contraintes sur 
un diagramme, comme le montre la figure 3.45. 



Figure 3.45 

Contraintes de 
duree exprimees 
sur un diagramme. 



: Emetteur 



{ < 1 jour } 

d 

d' 

d' - d < 1 jour j 



messa se ) 
transmettre( message ) 



transmettre( message ) 



: Destinataire 



Exercice 4 Messages perdus, trouves ou envoyes dans des flots 
d'execution paralleles 



Figure 3.46 

Demande 
d'execution de 
programmes. 



Completez les messages des figures 3.46 et 3.47 en choisissant le type de message approprie 
(perdu, trouve ou s'executant dans des flots d'execution paralleles). 

1. Demande d'execution de deux programmes par un systeme d'exploitation. 



SystemeDExploitation 



executer( programme = 
executer( programme = 



"lecteur CD" ) 
"editeur de texte" ) 



: Processeur 



Figure 3.47 

Transmission 
d'un virus a un 
ordinateur. 



2. Transmission d'un virus a un ordinateur. 



: Virus 



: Ordinateur 
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Solution 



Figure 3.48 

Envoi simultane 
de deux messages. 



1. Si le systeme Sexploitation est considere comme multitache, F execution des deux pro- 
grammes se fait simultanement, dans deux flots d'execution paralleles notes a et b. 

objet actif 



Figure 3.49 

Utilisation de 
messages perdu 
et trouve. 




a : executer( programme = "lecteur CD" ) 

b : executer( programme = "editeur de texte" ) 



: Processeur 



2 .La plupart du temps, un ordinateur contamine ne connait pas la source du virus 
et l'auteur du virus ne souhaite pas etre connu, d'ou Futilisation de messages perdu et 
trouve. 



: Virus 



: Ordinateur 



diffuser( virus ) 



attraper( virus ) 



message perdu 



message trouve 



Exercice 5 Fragments d'interaction combines pour decrire une methode 



COMPLEXE 



Le programme suivant, ecrit en pseudo-code, permet de calculer le factoriel d'un nombre 
n : 

int factoriel( int n ){ 

if ( n == 0 ) return 1 ; 
return n * factoriel( n-1) ; 

} 

ou n 0 et f actoriel( 0 ) = 1. 

Representez le programme precedent sur un diagramme de sequence. 



La solution (figure 3.50) utilise Foperateur alternative pour realiser le test sur la valeur de n. 
Notez aussi la superposition d'une deuxieme ligne de vie sur la premiere pour materialiser 
Fappel recursif de Foperation factorielle. Le nom de la ligne de vie, X, est fictif. 
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Figure 3.50 

Representation du 
calcul de la fonction 
factorielle sur un 
diagramme de 
sequence. 



sd calcul d'un factoriel 



+n : integer { n >= 0 1 



+f : integer 



factoriel( n) 



: X 



alt I [ n == 0 ] 

factoriel( n) 



[ else ] 



factoriel( n ) : n * f 



^factoriel( n-1 ) 
_jf = factoriel( n-1 ) 



appel recursif 



Exercice 6 Operateurs d'interaction 



Enonce 



Dessinez un diagramme de sequence qui presente trois objets : un robot + deux capteurs 
(une camera et un detecteur de chocs). Le diagramme doit contenir un fragment d'inter- 
action qui montre que les capteurs fonctionnent en meme temps (ils peuvent envoyer a 
tout moment des messages au robot). 



Solution 



Figure 3.51 

Utilisation de 
I'operateur par 
pour un probleme 
de robotique. 



sd Deplacement d'un robot )" 



: Camera 



: Robot 



par 



! analyserlmage( image )| 



1 



.1 



: DetecteurChocs 



IT 



T 



J 



eviterObstacle() 



116 UML 2 



Chapitre 



Remarque 

Avec l'operateur par, la sequence des evenements d'un operande peut etre interrompue 
par d'autres occurrences d'evenement venant d'autres operandes. A certains moments, les 
interruptions sont malvenues. Si Ton ajoute au robot un pilote et un moteur (figure 3.52), le 
pilote a un role preponderant et doit pouvoir d tout moment demander I'arret d'urgence du 
robot. La demande d'arret doit etre imperativement suivie de I'arret du moteur du robot. 
L'operateur critical est utilise pour definir une section critique, c'est-d-dire une region d'une 
interaction ou les traitements sont atomiques (realises en un bloc insecable). 
Parfois, I'entrelacement des evenements provenant de plusieurs operandes n'est pas souhai- 
table pour tous les participants (les lignes de vie) d une interaction. L'operateur seq empeche 
I'entrelacement des occurrences d'evenement sur une mime ligne de vie partagee par plu- 
sieurs operandes (c'est I'ordre des operandes qui fixe le sequencement). L'entrelacement 
n'est possible que sur des lignes de vie differentes non soumises d l'operateur seq. 



Figure 3.52 

Une region ou les 
operations sont 
atomiques. 



sd Displacement d'un robotP 



: Pilote 




: Camera 




: Robot 




: Moteur 




: DetecteurChocs 



par 



1 1 

analyserlmage( image ) 



H 



critical J 



eviterObstacleQ 



LT 



arreterDUrgence() 



arreter () 



V 



EXERCICE 7 DlAGRAMMES DE SEQUENCE POUR ILLUSTRER DES CAS D'UTILISATION 



Enonce 



Le diagramme de cas d'utilisation presente a la figure 3.53 modelise la gestion simplifiee 
d'une bibliotheque. 



Figure 3.53 

Diagramme de cas 
d'utilisation d'une 
bibliotheque. 



Bibliothecaire 




Gestion des emprunts 




Le fonctionnement de la bibliotheque est le suivant : une bibliotheque propose a ses adhe- 
rents des ceuvres litteraires ; les oeuvres peuvent etre presentes en plusieurs exemplaires ; 
un adherent peut emprunter jusqu'a trois livres. 
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Enonce (suite) 



1. Ecrivez a Faide d'un diagramme de sequence un scenario nominal d'emprunt. 

2. Ecrivez a Faide de diagrammes de sequence des scenarios d'emprunt alternatifs et 
d'exceptions. 



1. Pour decrire un scenario d'utilisation d'un cas, il faut considerer le systeme comme une 
boite noire et ne pas chercher a montrer des objets au coeur du systeme. Rappel : un cas 
d'utilisation est une grande fonction du systeme vue par un acteur ; il ne faut done pas 
faire figurer la structure interne d'un systeme (e'est le role du diagramme de classes). A la 
figure 3.54, le systeme est represents par une seule ligne de vie appelee Bibliotheque. 



Figure 3.54 

Description d'un 
scenario nominal 
a I'aide d'un 
diagramme de 
sequence. 



sd gestion des emprunts 



: Bibliotheque 



Bibliothecaire 



rechercher un adherent 



adherent trouve 



verifier si 1' adherent peut emprunter 



1' adherent peut emprunter 



rechercher une ceuvre 



ceuvre trouvee 



verifier s'il y a un exemplaire disponible pour cette oeuvre 



II y a un exemplaire disponible 



decrementer le nombre d'exemplaires dans la bibliotheque 



attribuer 1' exemplaire a 1' adherent 



Remarque 

Quand un diagramme de sequence decrit un cas d'utilisation, le formalisme strict d'UML (la 
syntaxe des messages par exemple) est plus libre. 

La description d'un scenario par un diagramme de sequence n'empeche pas de decrire le 
cas sous forme textuelle (voir chapitre 1 ), ce qui permet de faire figurer des renseignements 
supplementaires (pre- et post-conditions, contraintes...). 
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2. Le diagramme de la figure 3.55 complete le diagramme precedent (figure 3.54) en 
incluant la verification de contraintes. Si une contrainte n'est pas verifiee, les evenements 
qui suivent cette contrainte sont invalides. De plus, la sequence doit imperativement se 
terminer par les deux messages « decrementer le nombre d'exemplaires dans la biblio- 
theque » et « attribuer l'exemplaire a l'adherent » a cause de l'utilisation de l'operateur 
assert. 



Figure 3.55 

Utilisation de 
contraintes et de 
l'operateur assert 
dans un diagramme 
de sequence. 



sd gestion des empruntsj 



Bibliothecaire 



: Bibliotheque 



rechercher l'adherent 



adherent trouve 

u 



verifier si l'adherent peut emprunter 



adherent peut emprunter 

P 



rechercher une ceuvre 



ceuvre trouvee 



u 



verifier s'il y a un exemplaire 
disponible pour cette ceuvre 



assert ~J ~ 



exemplaire disponible 



decrementer le nombre 
d'exemplaires dans la bibliotheque 



attribuer l'exemplaire a l'adherent 



Le formalisme des diagrammes de sequence est tres riche. Souvent, il est possible de repre- 
senter des scenarios de plusieurs facons. Au lieu d'utiliser des operateurs d'assertion, il est 
possible de recourir a des operateurs d'alternative. 



CO 

0) 
U 

u 

I_ 

0 

X 

LU 
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La figure 3.56 presente une troisieme solution qui utilise un operateur d'option (l'operateur 
d'option opt est identique a un operateur d'alternative, mais avec un choix unique). 



Figure 3.56 

Utilisation des 
operateurs opt 
et neg. 



sd gestion des emprunts 



7 



: Bibliotheque 



Bibliothecaire 



rechercher 1' adherent 



opt ) 



[ adherent non trouve ] 



verifier si 1' adherent peut emprunter 



rechercher une ceuvre 



neg 



verifier s'il y a un exemplaire disponible pour cette ceuvre 



decrementer le nombre d'exemplaires dans la bibliotheque 



attribuer l'exemplaire a l'adherent 



La figure 3.56 utilise l'operateur negative pour indiquer que les messages sur lesquels il 
s'applique sont invalides. 



Exercice 8 Fragments d'interaction combines 





Enonce 1 


Construisez un diagramme de sequence ayant trois lignes de vie 
Passager. 

Comment interdire aux passagers d'ouvrir les portes quand le train 


Conducteur, Train et 
a demarre ? 





La solution utilise l'operateur negative pour interdire l'ouverture des portes (figure 3.57). 
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Figure 3.57 

Utilisation de 
I'operateur negative 

Pour interdire 
ouverture des 
portes d'un train. 



sd Conduire Train 



7 



: Conducteur 



deraarrer() 



: Train 




Chapitre 



: Passager 



ouvrirPorte() 



EXERCICE 9 DlAGRAMMES DE SEQUENCE POUR ILLUSTRER DES COLLABORATIONS 



Figure 3.58 

Diagramme de 
classes d'une 
mediatheque. 



L'exercice 7 montre comment utiliser des diagrammes de sequence pour decrire des cas 
d'utilisation. L'exercice 9 prolonge l'exemple de la bibliotheque en partant de l'hypothese 
qu'un diagramme de classes a ete construit (figure 3.58). Le but a present est de montrer 
comment des objets au cceur du systeme interagissent pour realiser les fonctions des cas 
d'utilisation. 

Le diagramme de classes presente a la figure 3.58 modelise la structure interne de la biblio- 
theque. Un adherent peut emprunter un exemplaire d'une oeuvre donnee. L'emprunt se 
fait de la facon suivante : l'operation emprunter de la classe Qjwvre est invoquee pour un 
adherent donne en argument ; s'il reste des exemplaires dans la bibliotheque, Fun des 
exemplaires associes a l'ceuvre est extrait via la methode extraireExemplaire, une instance 
de la classe Pret est creee, puis l'exemplaire extrait de la bibliotheque est attribue a l'adhe- 
rent grace a l'invocation de l'operation attribuer. 



Adherent 



attribuer( Exemplaire ) 



Pret 



date 



~1 

I 

I 0..3 



emprunte 



Exemplaire 



l..n 



(Euvre 



extraireExemplaire() : Exemplaire 
emprunter( Adherent ) 



1. Parmi les classes du diagramme precedent (figure 3.58), donnez la liste de celles qui 
permettent de realiser le comportement entoure par un cercle dans le diagramme de 
sequence presente a la figure 3.59. 
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Enonce (suite) 




Figure 3.59 

Diagramme de 
sequence de 
I'emprunt d'un 
livre. 



sd gestion des emprunt s, 



Bibliothecaire 



rechercher un adherent 



adherent trouve 



verifier si 1' adherent peut emprunter 



l'adherent peut emprunter 



rechercher une oeuvre 



ceuvre trouvee 



: Bibliotheque 




Verifier s'il y a un exemplaire disponible pour cette oeuvre 



II y a un exemplaire disponible 



decrementer le nombre d'exemplaires dans la bibliotheque 



attribuer 1' exemplaire a l'adherent 




2. Dessinez une collaboration montrant des instances des classes trouvees a la question 1. 

3. Representez les interactions au sein de la collaboration a l'aide d'un diagramme de 
sequence. 



1. Les classes impliquees sont Exemplaire, Qiuvre, Adherent et Pret. 

La classe Pret n'est pas mentionnee dans le diagramme de sequence, et pourtant elle est 
incluse dans la liste. C'est une classe d'association presente dans le diagramme de classes. 
Une instance de la classe Pret doit etre creee au moment de I'emprunt. 

2. Des instances des classes Exemplaire, (Euvre, Adherent et Pret sont reunies dans une 
collaboration (figure 3.60). Rappel : les liens entre les instances sont des connecteurs qui 
representent des associations transitoires etablies le temps que dure la collaboration. 
Parmi les connecteurs, on retrouve les associations du diagramme de classes. En plus, 
un nouveau lien apparait entre les instances & Adherent et d'CEuvre afin de materialiser 
la transmission d'un adherent comme argument de l'operation emprunter de la classe 
CEwvre. 
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Figure 3.60 

Diagramme de 
collaboration pour 
I'emprunt d'un 
exemplaire. 



Argument 
d'une operation 



Attribution d'un exemplaire a un adherent 



oeuvreTrouvee : (Euvre 




adherentTrouve : Adherent 


1 


exemplaireDisponible : Exemplaire 



: Pret 




Chapitre 



associations 



3 .Le diagramme de sequence est presente a la figure 3.61. L'interaction est decomposed en 
fragments combines qui utilisent l'operateur alternative : le choix porte sur la presence 
ou non d'un exemplaire disponible dans la mediatheque. Notez la creation d'une ins- 
tance de la classe Pret materialisee par un message qui pointe sur la tete de la ligne de vie. 



Figure 3.61 

Diagramme de 
sequence pour 
I'emprunt d'un 
exemplaire. 



nit 



sd AttributionExemplaireAAdherent( inout adherentTrouve : Adherent, inout oeuvreTrouvee : (Euvre ) 



+CEuvre.nombreExemplaires : integer { no mbreExempl aires >= 0} 



oeuvreTrouvee: (Euvre 



exemplaireTrouve : Exemplaire 



emprunter( adherentTrouve ) 



T 



adherentTrouve : Adherent 



[ nombreExemplaires > 0 ] 



emprunter : ok 



extraireExemplaireQ : Exemplaire 
I 
I 



I 
I 

attribuer( exemplaireTrouve ) 



I 



[ else ] 



emprunter : non ok 



Remarque 

Le formalisme des diagrammes de sequence est tres proche de celui des langages de pro- 
grammation (on peut representer aisement des tests, des boucles...). Les diagrammes de 
sequence sont principalement utilises durant la phase d'analyse. Cette etape ne doit pas 
etre confondue avec les phases de conception et d'implementation. Durant I'analyse, les 
interactions servent souvent d valider un diagramme de classes (en montrant comment des 
instances de classes interagissent). Veillez d ne pas faire d ce moment-Id des choix de 
conception ou d'implementation (voir chapitre 6). 
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La creation d'une instance dans un diagramme de communication peut etre materialisee 
par une contrainte, comme le montre la figure 3.62. 

Les contraintes {detruit} et {transitoire} peuvent etre placees sur des liens ou sur des objets 
pour indiquer leur destruction ou bien qu'ils sont temporaires. 



Figure 3.62 

Representation de la 
creation d'un objet 
et d'un lien dans 
un diagramme de 
communication. 



com emprunter 



7 



emprunter() 
> 



: (Euvre 



: Pret 



Exercice 1 0 Reutilisation d'une interaction 



Enonce 



Le diagramme de sequence de l'exercice 9 (figure 3.61) represente la fin du scenario nomi- 
nal de l'emprunt (partie entouree par un cercle dans le diagramme de la figure 3.59). Sup- 
primez la partie encerclee du scenario nominal et indiquez comment vous pouvez 
reutiliser le diagramme de sequence de la figure 3.61 a la place. 



Solution 



Fig 



ur< 



3 63 



Diagramme de 
sequence qui 
reference une 
interaction. 



sd gestion des emprunts j 



: Bibliotheque 



Bibliothecaire 



rechercher un adherent 



adherent trouve 



verifier si 1' adherent peut emprunter 



1' adherent peut emprunter 



rechercher une ceuvre 



(Euvre trouvee 



ref 



AttributionExemplaireAAdherent( adherentTrouve, ceuvreTrouvee ) 
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EXERCICE 1 1 DlAGRAMMES DE SEQUENCE POUR ILLUSTRER LES INTERACTIONS DANS 
UN CLASSEUR STRUCTURE 



Figure 3.64 

Une classe 
representor^ 
une file. 



Au moment de la conception d'un systeme, le concepteur part du resultat de Fanalyse (qui 
a defini ce que doit faire le systeme), et cherche comment realiser ce systeme. II procede 
par decompositions successives des classes pour definir les structures de donnees sous- 
jacentes. Le but de cet exercice est d'utiliser les classeurs structures d'UML pour decom- 
poser une classe, puis d'illustrer les interactions entre les elements d'un classeur structure 
par un diagramme de sequence. 

Une file est une structure de donnees dans laquelle les donnees sont ajoutees a la fin et 
extraites a partir du debut. La file est modelisee par une classe possedant les operations 
ajouter et extraire (figure 3.64). 



File 



ajouter( Donnee ) 
extraire() : Donnee 



Un classeur structure peut etre utilise pour montrer la structure interne de la file (figure 
3.65). Le concepteur choisit d'implementer la file en recourant a un tableau (une file est un 
tableau dans lequel on a restreint les acces aux deux extremites). Afin de decrire le com- 
portement du tableau lors de l'extraction d'un element, le concepteur decide d'utiliser une 
interaction appelee Extraire de la file. 



Figure 3.65 

La file vue comme 
un classeur 
structure. 



File 



Extraire de la file 



: Tableau 



Representez l'interaction Extraire de la file a l'aide d'un diagramme de sequence. Indica- 
tion : la facon la plus simple d' extraire le premier element d'un tableau est de memoriser la 
valeur de celui-ci avant de decaler les elements suivants, comme le montre la figure 3.66. 



Figure 3.66 

Extraire le premier 
element d'un 
tableau. 
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Solution 



La solution est presentee a la figure 3.67, ou une boucle est utilisee pour realiser le decalag 
Les operations add et get permettent d'ajouter et d'extraire un element du tableau. 



Figure 3.67 

Un diagramme 
de sequence pour 
illustrer I'extraction 
du premier element 
d'une file. 



sd extraire de 



la filej 



premier : Exemplaire 
suivant : Exemplaire 



: File 



: Tableau 



extraireQ 



luup( 1, n)J 



extraire() : premier 



get( 0 ) 



premier = get( 0 ) 



precedent = get( 0 ) 



add(precedent, i ) 
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Diagramme 
d'etats-transitions 



1 . Modelisation d I'aic 
d'automates 1 28 

2. Hierarchie dans les machines 

d etats 1 33 

3. Contrat de comportement 1 38 

4. Gestion de la concurrence 1 39 

Problemes et exercices 

1 . Diagramme d'etats-transitions 
d'un individu du point de vue 

de I'INSEE 142 

2. Diagramme d'etats-transitions 
d'une porte 1 43 

3. Diagramme d'etats-transitions 
d'une montre chronometre 1 45 

4. Modelisation de la socket TCP.. . 1 48 



Les diagrammes d'etats-transitions (ou statecharts) d'UML 
decrivent le comportement interne d'un objet d I'aide d'un 
automate d etats finis, lis presentent les sequences possibles 
d'etats et d'actions qu'une instance de classe peut traiter au 
cours de son cycle de vie en reaction d des evenements 
discrets (de type signaux, invocations de methode). 
lis specifient habituellement le comportement d'une instance 
de classeur (classe ou composant), mais parfois aussi le 
comportement interne d'autres elements tels que les cas 
d'utilisation, les sous-systemes, les methodes. lis sont bien 
adaptes d la description d'objets ayant un comportement 
d'automate. Cependant, la vision globale du systeme est 
moins apparente sur ces diagrammes, car ils ne s'interessent 
au'd un seul element du systeme independamment 
de son environnement. Les diagrammes d'interactions 
(voir chapitre 3) permettent de lier les parties du systeme 
entre elles. 
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□ Model isation d I 'aide d'automates 

1.1 Etat 



Un diagramme d'etats-transitions est un graphe qui represente un automate a etats finis, 
c'est-a-dire une machine dont le comportement des sorties ne depend pas seulement de 
l'etat de ses entrees, mais aussi d'un historique des sollicitations passees : cet historique est 
caracterise par un etat. 

Ainsi, l'effet d'une action sur un objet depend de son etat interne, qui peut varier au cours 
du temps. Par exemple, considerez une lampe munie de deux boutons-poussoirs : une pres- 
sion sur On allume la lampe et une pression sur O/fT'eteint. Une pression sur On ne produit 
pas d'effet si la lampe est deja allumee ; la reaction d'une instance de Lampe a cet evenement 
depend de son etat interne. 



Exemple La lampe 

Cet exemple simple presente la notion d'etat et l'effet des invocations en fonction de l'etat 
co u rant. 



Figure 4.1 

Un diagramme 

d'etats-transitions 

simple. 
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b 



Off 



Les etats sont represented par des rectangles aux coins arrondis, tandis que les transitions 
sont representees par des arcs orientes liant les etats entre eux. Certains etats, dits « compo- 
sites », peuvent contenir des sous-diagrammes. UML offre egalement un certain nombre de 
constructions a la semantique particuliere, telles que l'historique, qui permet de retrouver 
un etat precedent, les points de choix, qui permettent d'exprimer des alternatives, ou 
encore un moyen d'exprimer des mecanismes concurrents. 



EXEMPLE Fenetre d'application 

Le diagramme de la figure 4.2 presente le comportement simplifie d'une fenetre d'applica- 
tion, qui repond aux stimuli de trois boutons places dans Tangle. Une fenetre peut etre dans 
trois etats : reduite, normale, agrandie. Lorsqu'elle est reduite, elle est representee par une 
icone dans la barre des taches. A l'etat normal, elle peut etre deplacee et redimensionnee. 
Lorsqu'elle est agrandie, elle occupe toute la surface disponible de I'ecran et ne peut etre 
deplacee ou redimensionnee. Les arcs portent une etiquette indiquant le nom de I'evenement 
qui declenche la transition associee. L'etat initial (Init 1 et Init 2 ici), note par un cercle plein, 
designe le point d'entree du diagramme ou du sous-diagramme. Une nouvelle instance de 
fenetre sera initialisee a l'etat creee, dans le sous-etat ouverte et dans le sous-etat normale. Le 
pseudo-etat historique, designe par un H dans un cercle, permet de retrouver la fenetre son 
etat precedent [normale ou agrandie) quand on quitte l'etat reduite. L'etat final, designe par 
un point dans un cercle correspond d la fin de vie de I'instance et d sa destruction. 
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Figure 4.2 

Le comportement 
d'une fenetre 
d'application. 
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1 .2 EVENEMENT 



La vue proposee par les diagrammes d'etats-transitions met en evidence les reactions d'une 
partie du systeme a des evenements discrets. Un etat represente une periode dans la vie 
d'un objet dans laquelle ce dernier attend un evenement ou accomplit une activite. Quand 
un evenement est recu, une transition peut etre declenchee qui va faire basculer l'objet 
dans un nouvel etat. 

Les transitions d'un diagramme d'etats-transitions sont done declenchees par des evene- 
ments, appeles « declencheurs » ou triggers. La notion d'evenement est assez large en UML : 

• Un appel de methode sur l'objet courant genere un evenement de type call. 

' Le passage de faux a vrai de la valeur de verite d'une condition booleenne genere implici- 
tement un evenement de type change. 

• La reception d'un signal asynchrone, explicitement emis par un autre objet, genere un 
evenement de type signal. 

• L'ecoulement d'une duree determinee apres un evenement donne genere un evenement 
de type after. Par defaut, le temps commence a s'ecouler des l'entree dans l'etat courant. 

• La fin d'une activite de type do/, interne a un etat genere implicitement un evenement 
appele completion event. Cela peut declencher le tir des transitions dites « automati- 
ques », qui ne portent pas de declencheur explicite. 



Notation et specification 

Un evenement de type call ou signal est declare ainsi : 

nom-evenement '(' liste-parametres ')' 
ou chaque parametre a la forme : 

nom-parametre ' : ' type-parametne 

Les evenements de type call sont done des methodes declarees au niveau du diagramme de 
classes. Les signaux sont declares par la definition d'une classe portant le stereotype signal, 
ne fournissant pas d'operations, et dont les attributs sont interpretes comme des arguments. 
Un evenement de type change est introduit de la facon suivante : 

when '(' condition-booleenne ')' 
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Notation et specification [suite) 




II prend la forme d'un test continu et se declenche potentiellement a chaque changement de 
valeurs des variables intervenant dans la condition. 
Un evenement temporel de type after est specifie par : 

after 1 ( 1 parametre 1 ) 1 

ou le parametre s'evalue comme une duree, a priori ecoulee depuis I'entree dans I'etat cou- 
rant. Par exemple : afterflO secondes) ou afterflO secondes apres I'entree dans I'etat A). 
Vous pouvez aussi specifier un declencheur lie a une date precise par une clause when( j, 
par exemple when(date= I janvier 2000). 



Les declarations d' evenement ont une portee de niveau paquetage et peuvent etre utilisees 
dans tout diagramme d'etats-transitions des classes du paquetage. Leur portee n'est en 
aucun cas limitee a une classe. 



Particularites des evenements de type signal 

Un signal est un message emis de facon asynchrone, c'est-a-dire que Fappelant peut pour- 
suivre son execution sans attendre la bonne reception du signal. Ce type de communication 
a un sens uniquement lorsque plusieurs processus ou objets actifs sont en concurrence, en 
particulier lorsque l'instance cible est munie d'un flot de controle independant de celui de 
l'appelant. L' utilisation de signaux a la place de methodes peut accroitre les possibilites 
de concurrence et permet de modeliser certains types de communications materielles 
(interruptions materielles, entrees/sorties) ou en mode deconnecte (le protocole UDP sur 
IP par exemple). L'emission et la reception d'un signal constituent done deux evenements 
distincts. 



EXEMPLE Declaration de signaux 

A la figure 4.3, trois signaux sont declares comme des classes du paquetage et peuvent etre 
lies entre eux par des relations d'heritage. Si le signal A derive du signal B, il declenche par 
transitivite toutes les activites liees d B en plus des siennes propres. Les attributs de classe sont 
interpretes comme les arguments de I'evenement de type signal. 



Figure 4.3 

Declarations de 
signaux et heritage. 



«signal» 
Interruption E/S 



+peripherique :int 



«signal» 
Souris 



+posx:int 
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Clavier 



+caractere: int 
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1 .3 Transition simple 



Une transition entre deux etats simples El et E2 est representee par un arc qui les lie l'un a 
l'autre. Elle indique qu'une instance dans l'etat El peut entrer dans l'etat E2 et executer cer- 
taines activites, si un evenement declencheur se produit et que les conditions de garde sont 
verifiees. On parle de tir d'une transition quand elle est declenchee. 



Notation 

Une transition d'un diagramme d'etats-transitions est representee par un arc plein, liant un 
etat dit « source » d un etat « cible ». Elle est dotee d'une etiquette contenant une expres- 
sion de la forme : 

nom-evenement '(' liste-param-evenement ')' '[' garde ']' '/' activite 

ou les parametres eventuels de I'evenement sont separes par des virgules, la garde (par 
defaut vraie) designe une condition qui doit etre remplie pour pouvoir declencher la transi- 
tion, et I'activite exprimee dans une syntaxe laissee libre designe des instructions a effectuer 
au moment du tir. 

Le declencheur de la transition est un evenement de type call, signal, change ou after, ou 
n'est pas specifie pour les transitions automatiques (voir la section « Evenement »). L'evene- 
ment peut porter des parametres, visibles dans les activites associees a la transition ainsi 
que dans I'activite exit de l'etat source et I'activite entry de l'etat cible. Les evenements 
entrants sont traites sequentiellement. Si aucune transition n'est declenchee par I'evene- 
ment, il est detruit. Si une transition est declenchee, sa garde est evaluee ; celle-ci est expri- 
mee en fonction des variables d'instance et eventuellement de tests d'etat des instances 
d'objet accessibles (par exemple, ob j 1 in Etatl ou ob j 1 not in Etatl) ; si elle est 
fausse, I'evenement est detruit. Si plusieurs transitions sont simultanement franchissables, 
I'une d'entre elles est choisie de facon arbitraire. 



1 .4 Point de decision 



II est possible de representer des alternatives pour le franchissement d'une transition. On 
utilise pour cela des pseudo-etats particuliers : les points de jonction (representes par un 
petit cercle plein) et les points de choix (representes par un losange). 

Les points de jonction sont un artefact graphique qui permet de partager des segments de 
transition. Plusieurs transitions peuvent viser et/ou quitter un point de jonction. Tous les 
chemins a travers le point de jonction sont potentiellement valides. On peut done represen- 
ter un comportement equivalent en creant une transition pour chaque paire de segments 
avant et apres le point de jonction. L'interet est de permettre une notation plus compacte et 
de rendre plus visibles les chemins alternatifs. 

EXEMPLE Equivalences de representation 

Les deux representations des figures 4.4 et 4.5 sont equivalentes. 
L'utilisation des points de jonction rend les diagrammes plus lisibles. 
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Figure 4.4 

Utilisation de points 
de jonction. 



Figure 4.5 

Equivalence avec 
des transitions 
gardees. 
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Cette equivalence avec une representation par plusieurs transitions implique que, pour que 
Ton puisse emprunter un chemin, toutes les gardes le long de ce chemin doivent s'evaluer a 
vrai des le franchissement du premier segment. Les points de jonction ne constituent done 
qu'un sucre syntaxique, sans semantique particuliere. 

On dispose egalement du point de choix dit « dynamique », represente par un losange. Au 
contraire d'un point de jonction, les gardes apres ce point de choix sont evaluees au moment 
ou il est atteint. Cela permet en particulier de baser le choix sur des resultats obtenus en 
franchissant le segment avant le point de choix. Si, quand le point de choix est atteint, aucun 
segment en aval n'est franchissable, le modele est mal forme. Au contraire, si plusieurs 
segments sont franchissables, on suit la regie habituelle : quand plusieurs transitions sont 
simultanement franchissables, l'une d'entre elles est choisie aleatoirement. 



EXEMPLE 



Figure 4.6 

Utilisation d'un 
point de jonction. 



Point de choix dynamique 

Un formulaire en ligne est rempli par un utilisateur. Quand il valide son formulaire en 
appuyant sur le bouton go, une verification de la coherence des donnees fournies est realisee 
par validerEntree(). Si les informations paraissent correctes, on lui demande de confirmer, 
sinon on affiche les erreurs detectees et il doit remplir de nouveau le formulaire. Notez que la 
validation se fait sur le segment avant le point de choix. Ce fonctionnement ne peut etre decrit 
par un simple point de jonction. 
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Fiqure 4.7 

Deux points de 
jonction pour 
representer des 
alternatives. 
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0 Hierarchie dans les machines a etats 



II est possible d'utiliser une garde particuliere sur un des segments apres un point de choix 
ou de jonction en introduisant une clause [else]. Ce segment n'est franchissable que si les 
gardes des autres segments sont toutes fausses. L'utilisation d'une clause [else] est recom- 
mandee apres un point de choix car elle garantit un modele bien forme. 

Si Ton utilise un point de jonction pour representer le branchement d'une clause condition- 
nelle, il est conseille d'utiliser egalement un point de jonction pour faire apparaitre la fin du 
branchement et etre homogene. 

Point de jonction representant des alternatives 

Le point de jonction est bien adapte a la representation de clauses conditionnelles de type 
if/endif. 

associer client et commande 



2.1 Etat et transition interne 



Un etat est une periode dans la vie d'un objet oil il verifie une condition donnee, execute 
une certaine activite, ou plus generalement attend un evenement. Conceptuellement, un 
objet reste done dans un etat durant une certaine duree, au contraire des transitions qui 
sont vues comme des evenements ponctuels (sauf dans le cas particulier ou la transition 
declenche elle-meme un traitement). 

Un etat peut etre decompose en deux compartiments separes par une barre horizontale. Le 
premier compartiment contient le nom de l'etat, le second contient les transitions internes 
de l'etat, ou activites associees a cet etat. Vous pouvez omettre la barre de separation en 
l'absence de transitions internes. Une transition interne ne modifie pas l'etat courant, mais 
suit globalement les regies d'une transition simple entre deux etats. Trois declencheurs 
particuliers sont introduits permettant le tir de transitions internes : entry/, do/, et exit/. 



EXEMPLE 

Figure 4.8 

La saisie d'un mot 
de passe. 



Representation d'un etat simple 



saisie mot de passe 



entry/ set echo invisible 
character/ traiter cararctere 
help/ afficher aide 
exit/ set echo normal 
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Notation 

La syntaxe de la definition d'une transition interne est la suivante : 

Nom-evenement 1 ( 1 liste-parametres ' ) 1 '['garde']' '/' activite-a-realiser 

Le nom de I'evenement peut etre celui d'une methode de I'objet auquel appartient I'etat, 
d'un evenement declare comme tel au niveau paquetage, ou un des mots-cles reserves 
suivants : 

• entry definit une activite d effectuer d chaque fois que Ton rentre dans cet etat. 

• exit definit une activite d effectuer quand on quitte cet etat. 

• do definit une activite continue qui est realisee tant que Ton se trouve dans cet etat, ou 
jusqu'd ce que le calcul associe soit termine. On pourra dans ce dernier cas gerer I'eve- 
nement correspondent d la fin de cette activite [completion event). 

• include permet d'invoquer un sous-diagramme d'etats-transitions. 

La liste des parametres (optionnelle) correspond aux arguments de I'evenement declen- 
cheur de I'activite. La condition d'activation, ou garde, est une condition booleenne qui 
permet d'autoriser ou non le declenchement de I'activite. La facon de specifier I'activite 
d realiser est laissee libre. En general, on utilise le langage naturel pour decrire I'activite d 
entreprendre, ou du pseudo-code mentionnant les arguments de I'evenement declencheur. 
On peut egalement utiliser une reference vers un autre diagramme (activite ou collabora- 
tion) pour decrire ce traitement. 

Une transition interne se distingue d'une transition representee par un arc qui boucle sur 
I'etat, car lors de l'activation d'une transition interne, les activites entry et exit ne sont pas 
appelees (on ne quitte pas I'etat courant). Implicitement, tout diagramme d'etats-transi- 
tions est contenu dans un etat externe qui n'est usuellement pas represente. Cela apporte 
une plus grande homogeneite dans la description : tout diagramme est implicitement un 
sous-diagramme. 

2.2 Etat composite 



Un etat composite, par opposition a un etat dit « simple », est graphiquement decompose 
en deux ou plusieurs sous-etats. Tout etat ou sous-etat peut ainsi etre decompose en sous- 
etats enchaines sans limite a priori de profondeur. Un etat composite est represente par les 
deux compartiments de nom et d'actions internes habituelles, et par un compartiment 
contenant le sous-diagramme. 



Exemple Combine telephonique 

Cet exemple presente les etapes de Taction composer numero. A I'entree dans I'etat compo- 
site (par exemple suite d une action decrocher), une tonalite sonore annonce que le telephone 
est pret pour la composition du numero. Les chiffres sont saisis un par un suite d I'appel de 
I'operation chiffrer. La transition automatique de numeroter vers I'etat final est franchie des 
que sa garde devient vraie. 
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Figure 4.9 

Composition 
d'un numero 
et transitions 
automatiques. 
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Un nouvel objet est cree dans l'etat initial le plus externe du diagramme et franchit la tran- 
sition par defaut qui en part. Un objet qui atteint l'etat final le plus externe est detruit. Ces 
transitions peuvent etre accompagnees d'une etiquette qui indique un evenement correspon- 
dant au constructeur ou destructeur d'instance, et eventuellement associees a une activite. 

Une transition qui atteint l'etat final d'un sous-diagramme correspond a la fin de Taction 
associee a l'etat l'encapsulant. La fin d'une activite interne d'un etat peut etre associee au 
declenchement d'un changement d'etat, represents par une transition sans etiquette qui 
quitte l'etat externe courant. On parle alors de transition automatique, declenchee par un 
evenement implicite de terminaison (completion event). Un completion event est egalement 
declenche par la fin d'une activite interne de type do/. 

L' utilisation d'etats composites permet de developper une specification par raffinements. II 
est parfois souhaitable de ne pas representer les sous-etats a chaque utilisation de l'etat 
englobant. Vous pouvez noter graphiquement le fait qu'un etat est composite et que sa 
definition est donnee sur un autre diagramme. 



EXEMPLE Notation abregee des etats composites 

Figure 4.1 0 

Representation compacte 
d'un etat composite. 



Composer 



2.3 Transition et etat composite 



Les transitions peuvent avoir pour cible la frontiere d'un etat composite et sont alors equi- 
valentes a une transition ayant pour cible l'etat initial de l'etat composite. De meme, une 
transition ayant pour source la frontiere d'un etat composite est equivalente a une transi- 
tion qui s'applique a tout sous-etat de l'etat composite source. Cette relation est transitive : 
la transition est franchissable depuis tout etat imbrique, quelle que soit sa profondeur. Si la 
transition ayant pour source la frontiere d'un etat composite ne porte pas de declencheur 
explicite (en d'autres termes, si elle est declenchee par un completion event), elle est fran- 
chissable quand l'etat final de l'etat composite est atteint. 

Par exemple, la transition minimiser de la fenetre d' application est franchissable depuis les 
etats normale et agrandie (voir figure 4.2). 

Les transitions peuvent egalement toucher des etats de differents niveaux d'imbrication, en 
traversant les frontieres des etats. 

Dans tous les cas, avant l'entree dans un etat (respectivement la sortie), les activites entry/ 
(respectivement exit/) sont realisees. En cas de transition menant vers un etat imbrique, les 
activites entry/ de l'etat englobant sont realisees avant celles de l'etat imbrique. En cas de 
transition depuis la frontiere de l'etat englobant, les activites exit/ du sous-etat actif sont 
realisees, puis celles de l'etat englobant le sont a leur tour. 
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EXEMPLE Ordre d'appel 

Depuis I'etat Etatll, la reception de I'evenement event) provoque la sequence d'activites 
QuitterEll, QuitterEl, action], EntrerE2, EntrerE21, initialiser, EntrerE22, et place le systeme 
dans I'etat Etat22. 



Figure 4.1 1 

Ordre des actions 
dans un cas 
complexe. 
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2.4 HlSTORIQUE ET ETAT COMPOSITE 



Chaque region ou sous-diagramme d'etats-transitions peut avoir un pseudo-etat histori- 
que, note par un cercle contenant un H. Une transition ayant pour cible le pseudo-etat his- 
torique est equivalente a une transition qui a pour cible le dernier etat visite dans la region 
contenant le H. 

Dans l'exemple de la fenetre presente precedemment a la figure 4.2, le pseudo-etat histori- 
que permet de retrouver I'etat precedent {normale ou agrandie) quand on sort de I'etat 
reduite. 

II est possible de definir un dernier etat visite par defaut a l'aide d'une transition ayant pour 
source le pseudo-etat H. Cet etat par defaut sera utilise si la region n'a pas encore ete visitee. 

II est egalement possible de definir un pseudo-etat historique profond, note par un cercle 
contenant H*. Cet historique profond permet d'atteindre le dernier etat visite dans la 
region, quel que soit son niveau d'imbrication, alors que le pseudo-etat H limite Faeces aux 
etats de son niveau d'imbrication dans la region. Toute region peut avoir a la fois un histo- 
rique profond et un historique de surface. 



EXEMPLE Historique 

['utilisation d'un historique profond permet de retrouver, apres une interruption, le sous-etat 
precedent. A la figure 4.12, I'utilisation d'un historique de surface H, au lieu de H*, permet- 
trait de retrouver I'etat Traitementl ou Traitement2 dans leur sous-etat initial, mais pas les 
sous-etats imbriques Ell, E12, E21 , E22, qui etaient occupes avant I'interruption. 
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Figure 4.1 2 

Historique et 
historique profond. 
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2.5 Interface des etats composites 



Pour cacher la complexity, il est possible de masquer, sur un diagramme, les sous-etats d'un 
etat composite et de les definir dans un autre diagramme. Pour exprimer la connexion des 
diagrammes entre eux, vous pouvez utiliser des points de connexion. Les points d'entree et 
de sortie sont respectivement represented par un cercle vide et un cercle barre a la frontiere 
de l'etat. 

Pour utiliser le comportement « par defaut » d'une machine a etat, c'est-a-dire entrer par 
l'etat initial par defaut et considerer les traitements finis quand l'etat final est atteint, il est 
inutile de se servir de ces points de connexion. Recourez plus simplement a des transitions 
ayant pour cible la frontiere de l'etat englobant. 

Employez plutot des points de connexion lorsqu'il est possible d'entrer ou de sortir de la 
machine a etats de plusieurs facons, par exemple pour representer des transitions traversant 
la frontiere de l'etat englobant et visant directement un autre sous-etat que l'etat initial 
(comme l'etat historique par exemple), ou ayant pour source un sous-etat et visant un etat 
externe. 

Un point de connexion n'est qu'une reference a un etat defini ailleurs. L'etat qu'il designe est 
signale par l'unique transition quittant le pseudo-etat. Cette transition peut eventuellement 
porter une etiquette indiquant une action (qui sera executee avant l'activite entry de l'etat 
cible), mais pas de garde ni de declencheur explicite : c'est le prolongement de la transition 
qui vise le point de connexion. 

Plusieurs transitions peuvent cibler un meme point de connexion. Cela peut rendre les dia- 
grammes plus lisibles. 



EXEMPLE Points de connexion 

Cet exemple montre I'utilisation des points de connexion. L'etat distribuer boisson a deux 
entrees et trois sorties. L'entree par defaut verifie d'abord que le credit de I'utilisateur est suffi- 
sant pour la boisson selectionnee, et peut provoquer une sortie sur erreur par le point de 
connexion credit insuffisant. Un deuxieme point d'entree est fourni pour I'operateur de main- 
tenance qui peut declencher la preparation d'une boisson sans inserer d'argent. La prepara- 
tion de la boisson peut elle-meme etre soumise d des erreurs. Dans le cas nominal, la boisson 
est preparee et la sortie de l'etat distribuer boisson se fait par l'etat final. 



Diagramme d'etats-transitions 1 37 



Figure 4.1 3 

Points de connexion 
pour la composition 
de diagrammes. 
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Les points de connexion sont plus qu'une facilite de notation : ils permettent de decoupler 
la modelisation du comportement interne d'un etat et la modelisation d'un comportement 
plus global. Ils offrent une facon de representer l'interface (au sens objet) d'une machine a 
etats, en masquant l'implementation du comportement. Cela permet un developpement 
par rafiinements (ou en bottom-up), en deux etapes independantes du processus de concep- 
tion, ce qui est essentiel pour traiter des modeles de grande taille. 



B Gontrat de comportement 

UML 2 introduit la notion de contrat de comportement (ou protocole d'utilisation d'un 
classeur), represente a l'aide d'un diagramme de protocole (une version simplifiee des 
diagrammes d'etats-transitions reconnaissable au mot-cle {protocol}). 

Un contrat de comportement definit les sequences d'actions legales sur un classeur, ainsi 
qu'un certain nombre de pre- et post-conditions qui doivent etre validees. II est relative- 
ment abstrait et n'exprime pas la nature des traitements realises, mais indique simplement 
leur enchainement logique. Ainsi, les etats d'un diagramme de protocole n'ont pas de 
clauses declenchant des activites {entry/, exit/, do/), et les transitions n'ont pas d'activites 
a declencher. 

Notation 

La syntaxe de I'etiquette d'une transition liant un etat source F7 d un etat destination E2 sur 
un diagramme de protocole est la suivante : 

'['pre-condition']' Declencheur '/' '['post-condition']' 

Une telle transition a le sens suivant : si le classeur est dans I'etat protocolaire El et si la 
pre-condition est vraie, la reception de I'evenement declencheur doit provoquer le passage 
dans I'etat E2, et a Tissue du franchissement, la post-condition doit etre vraie. 
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Les protocoles servent a expliquer la facon correcte de se servir d'une classe ou d'un compo- 
sant, sans specifier les traitements qui realisent Faction. Plusieurs implementations diffe- 
rentes d'une classe peuvent respecter un protocole donne. 



EXEMPLE 



Protocole d'une classe Fichier 

Ce diagramme decrit la facon de se servir d'une instance de classe descripteur de fichier. 
Avant de pouvoir I'utiliser vraiment (lecture, ecriture, positionnement du curseur dans le 
fichier), il faut I'associer d un fichier d I'aide de la methode open. Avant de detruire I'ins- 
tance, I'utilisateur doit appeler la methode close, pour eviter d'eventuels problemes d'entree/ 
sortie. Sur cet exemple, il n'y a pas de gardes. 



Figure 4.1 4 

Diagramme de 
protocole d'une 
classe fichier. 



stm {protocol} 
fichier 



1 



write/ 



close/ 



deconnecte 



open/ 



connecte 



seek/ 



delete/ 



V 



read/ 



□ Gestion de la concurrence 

Les diagrammes d'etats-transitions permettent de decrire efficacement les mecanismes 
concurrents. Un etat composite dote de sous-etats peut avoir un comportement concurrent, 
a travers Futilisation de regions concurrentes. Celles-ci permettent de representer des zones 
ou Taction est realisee par des flots d' execution paralleles. 

Chaque region d'un etat peut avoir un etat initial et final. Une transition qui atteint la 
bordure d'un etat composite est equivalente a une transition qui atteint l'etat initial du 
sous-diagramme ou les etats initiaux de toutes ses regions concurrentes si elles existent. Les 
transitions ayant pour origine un etat initial interne ne sont pas etiquetees et correspondent 
a toute transition atteignant la frontiere de l'etat externe. 

Quand un etat presente des regions concurrentes, elles doivent toutes atteindre leur etat 
final pour que Taction soit consideree comme terminee (generation d'un completion event). 



Exemple Etat concurrent 

Cet exemple montre un etat concurrent, au sein d'un distributeur de type machine d cafe. 
Quand la boisson a ete selectionnee et le montant valide par rapport au credit, deux sequen- 
ces d'actions sont declenchees en parallele : la preparation de la boisson et le rendu de la 
monnaie. 
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Regions concurrentes 
au sein d'un etat. 



boisson selectionnee 



preparer boisson 



entry/placer gobelet 
do/servir liquide 



terminer preparation 



do/aj outer sucre 
exit/signal sonore 



rendre monnaie 



entry/monnaie= credit - boisson.prixQ 
\do/monnayeur.rendre(monnaie) ( 



II est egalement possible de representer ce type de comportement au moyen de transitions 
concurrentes dites « complexes ». Ces transitions sont representees par une barre verticale 
epaisse et courte, eventuellement associee a un nom. Un ou plusieurs arcs peuvent avoir 
pour origine ou destination la transition. La semantique associee est celle d'un fork/ 'join. 



EXEMPLE Transition concurrente 

L'etat concurrent du distributeur de boisson peut etre specifie de facon equivalente a I'aide de 
deux transitions concurrentes. La transition nommee ici fork correspond a la creation de deux 
taches concurrentes creees dans les etats preparer boisson et rendre monnaie. La transition 
nommee join correspond d une barriere de synchronisation par rendez-vous. Pour pouvoir 
continuer leur execution, toutes les taches concurrentes doivent prealablement etre pretes d 
franchir la transition de rendez-vous. 



Figure 4.1 6 

Transition complexe 
pour I'expression 
de la concurrence. 



preparer boisson ^ 




f ~\ 
terminer preparation 


entry/placer gobelet 
do/servir liquide 





do/ajouter sucre 
exit/signal sonore 

J 



rendre monnaie 



entry/monnaie= credit - boisson.prix{) 
do/monnayeur.rendre(monnaie} 



gobelet retire/ 



do/a fficher « retirer boisson » 



Une transition ayant pour destination un etat cible muni de regions concurrentes est equi- 
valente a une transition complexe de type fork ayant pour cibles les etats initiaux de chaque 
region concurrente. Une transition ayant pour origine un etat source muni de regions 
concurrentes est equivalente a une transition complexe de type join ayant pour sources les 
etats finaux de chaque region concurrente. 
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Les diagrammes d'etats-transitions permettent de representer le comportement interne 
d'un objet, a fortiori actif, sous une forme qui met en avant le modele evenementiel ou reac- 
tif Acs traitements. lis sont bien adaptes au genie logiciel oriente objet, en raison des meca- 
nismes qu'ils proposent (evenement de type call, signal, after), qui permettent de faire le lien 
avec les autres diagrammes de la norme. La grande fiexibilite apportee par la possibility de 
defmir des transitions internes {entry, do, exit) et par les mecanismes de hierarchisation des 
diagrammes permet de representer de facon concise et formelle Fensemble des comporte- 
ments d'une instance modelisee. 

De ce point de vue, les diagrammes d'etats-transitions sont les seuls de la norme a offrir une 
vision complete et non ambigue de l'ensemble des comportements (les diagrammes d'inter- 
actions n'offrant que la vue d'un scenario, sans vraiment preciser comment les differents 
scenarios ebauches peuvent interagir entre eux). D'un autre cote, en raison de leur grand 
niveau de details et de leur lourdeur relative, ils sont surtout adaptes a la phase de realisa- 
tion. En outre, ils conviennent peu a la modelisation de systemes composes de plusieurs 
sous-systemes car ils n'offrent pas de vision globale. 

Les diagrammes de protocole donnent une vision de haut niveau du comportement d'un 
composant en specifiant ses responsabilites, sans entrer dans les details de son implementa- 
tion. Ils sont relativement proches de la notion d'interface d'un composant, tout en ajoutant 
une information supplemental par rapport a la seule description des signatures des opera- 
tions qu'il porte, a savoir des contraintes sur l'ordre d'appel des operations declarees. 

Outre leur interet lors de la modelisation, certains outils sont capables de generer auto- 
matiquement un programme a partir d'une description sous forme de diagrammes etats- 
transitions. Ainsi, chaque objet d'un systeme passe sous le controle d'un automate. Ce 
dernier connait l'etat de l'objet a tout instant, et en agissant comme un filtre, n'autorise les 
changements d'etats que s'il recoit une demande de transition valide. Le code produit est 
alors tres robuste car l'objet ne peut pas etre corrompu. De plus, le mode de controle du 
logiciel devient alors evenementiel. 

Avec les diagrammes presentes dans la partie precedente du livre (diagramme des cas d'uti- 
lisation, diagramme de classes et d'objets, diagramme de sequence et de communication, 
diagramme d'etats-transitions), un systeme peut etre presque entierement modelise. La 
modelisation n'est cependant pas assez avancee pour implanter le systeme. Les developpeurs 
par exemple ont besoin de decrire les algorithmes utilises pour definir les methodes des 
classes, sans pour autant avoir recours a un langage de programmation. Par ailleurs, certains 
modeles sont trop approximatifs. Considerez par exemple un systeme dont le comporte- 
ment est complexe. Dans ce cas, les diagrammes de sequence peuvent ne pas suffire a 
detailler les cas d' utilisation. Une partie de ces lacunes peuvent etre comblees grace aux 
diagrammes d'activites qui sont etudies au chapitre suivant. 
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Problemes 
et exercices 

Les exercices suivants utilisent les principaux concepts des diagrammes 
d'etats-transitions. 



EXERCICE 1 DlAGRAMME D'ETATS-TRANSITIONS D'UN INDIVIDU DU POINT DE VUE 

DE l'INSEE 



Representez par un diagramme d'etats-transitions les etats que peut prendre un individu 
du point de vue de l'INSEE : vivant, decede, mineur, majeur, celibataire, marie, veuf et 
divorce. 



Solution 



Supposez que seul un individu majeur peut se marier. Utilisez des etats composites pour 
cumuler les etats : un individu peut etre simultanement vivant, majeur, et divorce par 
exemple. 



Figure 4.1 7 

Un individu du point 
de vue de l'INSEE. 
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La machine a etats englobante est implicite ici. L' utilisation d'un evenement de type after 
permet de declencher le passage a l'etat majeur. Seules les transitions legales sont represen- 
tees : une personne ne peut se marier si elle est deja mariee. 

La transition deceder est franchissable quel que soit le sous-etat de vivant dans lequel se 
trouve un individu. 
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EXERCICE 2 DlAGRAMME D'ETATS-TRANSITIONS D'UNE PORTE 



Une porte munie d'une serrure offre les operations ouvrir, fermer, verrouiller, deverrouiller 
eXfranchir. La serrure peut etre fermee a simple ou a double tour. 

1. Commencez par modeliser les etats et transitions de la serrure. Mettez en avant les etats 
oil la serrure est verrouillee par rapport aux etats ou elle ne Test pas. 

2. Exprimez a travers un diagramme de protocole la facon normale de se servir d'une 
porte a verrou. 

3. Modelisez les etats et transitions d'une porte sans serrure. Ajoutez ensuite des annota- 
tions exprimant des contraintes pour Her ce diagramme a l'utilisation de la serrure. 



l.La serrure repond aux evenements verrouiller et deverrouiller. Vous pouvez dans un pre- 
mier temps vous contenter de modeliser les trois etats deverrouillee, simple tour et double 
tour. Utilisez un etat composite pour distinguer les etats ou la serrure est verrouillee. Sur 
le schema de la figure 4.18, nous avons employe la notation frame (cadre), avec l'indica- 
tion stm {State Machine), pour specifier le type et le nom du diagramme. 



Figure 4.1 8 

Les etats d'une 
serrure de porte. 



stm 
Serrure 



deverrouillee 



verrouiller 



1 



deverrouiller 



verrouillee 



simple tour 



verrouiller 
> 



deverrouiller 



double tour 



2. Un diagramme de protocole exprime la facon correcte de se servir d'un composant. Ici 
vous devez specifier qu'on ne verrouille la porte que quand elle est fermee. Une premiere 
version presentee a la figure 4.19 fait apparaitre quatre etats. 



Figure 4.1 9 

Le protocole 
d'utilisation 
d'une porte. 



{protocol} 
porte avec verrou 



fermerQ 



ouverte 



franchir() ouvrirQ 
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fermee 
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Cependant pour ameliorer la coherence avec le diagramme presente a la figure 4.18, vous 
pouvez utiliser un etat composite, dans lequel les etats precedemment identifies de la 
serrure sont presents. 
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Figure 4.20 

line autre modeli- 
sation du protocole 
d'utilisation d'une 
porte. 



{protocol} 
porte avec verrou 



7 



fermerQ 



franchir() ouvrir() 



fermee 



verrouiller() 



verrouiller() 



deverrouillee 



simple tour 



double tour 



deverroLiiller( ) 



deverrouiller() 



Ces deux modelisations sont tres similaires, mais la deuxieme decouple mieux les etats de 
la serrure et ceux de la porte elle-meme. 

3. La porte n'a que de deux etats (ouverte ou fermee) et reagit aux evenements ouvrir, fermer 
et franchir. Vous pouvez d'abord modeliser les etats ouverte et fermee et les transitions 
associees. Ajoutez ensuite les gardes qui contraignent les transitions par rapport aux etats 
de la serrure. La reference a l'etat de l'objet serrure suppose une variable de contexte 
accessible depuis l'objet englobant ce diagramme, c'est-a-dire la porte. 



Figure 4.21 

Les etats d'une porte. 



stm 
porte 



ouverte 



A 



franchir() 



[serrure deverrouillee] fermer()/ 



[serrure deverrouillee] ouvrirQ/ 



fermee 



Cette modelisation exploite la definition composite des etats de la serrure : il ne s'agit pas 
de savoir si la serrure est fermee a simple ou double tour, mais simplement si elle est 
verrouillee ou non. 



Remarque 

Cette modelisation decouple mieux les objets porte et serrure qu'une modelisation qui 
melangerait leurs machines a etats. Vous seriez alors oblige de faire figurer des etats 
comme ouverte et verrouillee a simple tour, ouverte et verrouillee a double tour, fermee et 
verrouillee..., ce qui augmenterait la complexity du diagramme inutilement et forcerait a 
copier-coller des parties de diagramme. 

['utilisation de gardes est mieux adaptee ici que I'utilisation d'une barre de synchronisation 
qui forcerait a melanger les diagrammes de la serrure et de la porte. Avec le modele 
obtenu, vous pourrez aisement reutiliser des parties pour modeliser une porte avec un digi- 
code par exemple. 

Enfin, notez que la porte telle qu'elle est definie par le diagramme de la figure 4.2 1 admet 
des scenarios absents du diagramme de protocole : il est egalement possible de la ver- 
rouiller quand elle est ouverte (ce qui empeche de la fermer correctement). Le diagramme 
de protocole donne done des informations non redondantes par rapport aux diagrammes 
d'etats-transitions : il decrit la bonne facon de se servir d'une porte. 
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DlAGRAMME D'ETATS-TRANSITIONS D'UNE MONTRE CHRONOMETRE 



Chapitre 



Cet exercice reunit trois exercices relativement independants, correspondant aux differentes 
fonctionnalites proposees. L' architecture logicielle proposee s'appuie sur le design pattern 
Observer. 



Remarque 




Le design pattern (ou patron de solution) Observer [Gamma 95] offre une solution propre 
aux problemes de mise d jour des donnees de classes liees entre elles. Un des problemes 
du partitionnement d'une application en classes est le maintien de la coherence des parties 
de I'application. Pour favoriser la reutilisabilite, il n'est pas souhaitable de coupler forte- 
ment les classes stockant les donnees (classes de type sujet) et celles qui les affichent ou plus 
generalement les utilisent (classes de type observateur). Pourtant, il faut assurer qu'une mise 
d jour des donnees des classes de type sujet sera correctement repercutee sur les classes de 
type observateur. 

Le design pattern Observer decrit une solution d ce probleme. Un sujet peut avoir un nombre 
indetermine d'observateurs et tous les observateurs sont notifies du changement quand le 
sujet subit une mise d jour. En reponse, les observateurs interrogent le sujet pour connaTtre 
son nouvel etat et mettre ainsi d jour leur propre etat. 

Une architecture de ce type est parfois qualifiee de publish/subscribe (publication/abonne- 
ment) : le sujet publie des notifications, les observateurs s'y abonnent s'ils le souhaitent. Le 
point important est que le sujet ignore quels sont ses observateurs, ce qui donne un modele 
bien decouple. 



Figure 4.22 

Design pattern 
Observer. 



Sujet 



+attacher( Observateur) 
+detacher(Observateur) 
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SujetConcret 


sujet 

— 
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etatObservateur 


setEtat() O-- 
getEtatQ Ok^ 




mettre a jour l'etat ; ^-A 
self. notify 0: 


update () ^ 
* 

\ 



return etatSuj 



etatObservateur = foo (sujet.getEtatQ) 



Une montre digitale propose une fonction horloge et une fonction chronometre. Elle est 
munie de quatre boutons : 

• Le bouton light, quand il est presse, allume une lumiere pendant une duree de deux 
secondes. 

• Le bouton mode active successivement trois modes principaux de la montre : l'affi- 
chage de l'heure courante, le mode chronometre et le mode reglage (pour mettre a 
jour l'heure courante). 




CO 

O 
U 

u 

o 

X 
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• Le bouton start-stop lance et arrete le chronometre en mode chronometre. II active 
successivement les fonctions de reglage de l'heure, des minutes ou des secondes en 
mode reglage. 

• Le bouton set incremente les heures, minutes et secondes en mode reglage et remet a 
zero le chronometre. 

Vous allez decomposer l'etude du fonctionnement de cette montre en plusieurs etapes. 

On vous donne la classe Timer qui sait gerer les dates/heures et est munie de toutes les opera- 
tions de mise a jour utiles. Sa methode startQ lance l'ecoulement du temps et stopQ l'arrete. 

1. filaborez un diagramme de classes qui permet de realiser le lien entre l'afficheur a cris- 
taux liquides de la montre et les instances de Timer gerant respectivement le chronome- 
tre et l'heure courante. 

2 .Modelisez dans un premier temps le comportement lie a l'utilisation du bouton mode 
de la montre. Ajoutez le comportement lie a l'utilisation de la lumiere (bouton light). 

3. En mode chronometre, le bouton start-stop lance ou arrete le chronometre. Le bouton 
set remet le chronometre a zero s'il est arrete. Modelisez ces comportements. 

Ajoutez la possibilite de retrouver l'etat precedent en changeant de mode : il est possible 
de lancer le chronometre, puis de basculer en mode affichage de l'heure et de revenir au 
mode chronometre : le chronometre continue de tourner pendant cette operation. 
(Vous pourrez utiliser un pseudo-etat historique.) 

4. En mode reglage, le bouton start-stop active successivement les fonctions de reglage de 
l'heure, des minutes ou des secondes. Le bouton set incremente l'heure courante d'une 
heure en mode reglage de l'heure, d'une minute en mode reglage des minutes, ou remet 
les secondes a zero en mode reglage des secondes. L'afficheur fait clignoter le champ 
selectionne. Modelisez ces comportements. 



Solution 



1. La montre dispose de deux instances de Timer, et d'un afficheur, accessibles depuis son 
contexte. On utilise une instance du design pattern Observer pour assurer la coherence 
continue entre l'affichage et l'etat interne de la montre. 



Figure 4.23 

Diagramme de 
classes simplifie 
d'une montre. 
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Montre 
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2. L'alternance entre les trois modes principaux se represente facilement a l'aide de trois 
etats. Le comportement lie a l'eclairage est independant du mode principal selectionne. 
Utilisez done des regions concurrentes pour exprimer cette independance. 



Figure 4.24 

Les principaux 
modes d'affichage 
et la lumiere. 



mode/ 



affichage heure 



entry/ 

afficheur.afficher(time) 




mode chrono 
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mode/ 



mode reglage 
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mode/ 



lumiere eteinte 



light/ 



after(2 sec) 



lumiere allumee 



light/ 



Le mode affichage de Fheure est relativement simple : quand on entre dans cet etat, on lie 
1'afficheur a Fheure courante ; les boutons set et start-stop sont alors sans effet. 

Les modes chronometre et reglage sont plus complexes et par la meme detailles separe- 
ment. Notez graphiquement que ce sont des etats composites, sans plus de precision. On 
introduit le point d'entree de l'etat mode chrono par souci de coherence avec la solution 
proposee a la question 3. A ce stade de la modelisation, vous pourriez vous contenter de 
toucher la frontiere de l'etat. 

La gestion de la lumiere donne lieu a deux etats, isoles dans une region concurrente. 
after(2sec) se mesure par defaut des l'entree dans l'etat lumiere allumee. Une nouvelle 
pression sur le bouton light quand la lumiere est deja active a done pour effet de remettre 
ce compteur a zero, puisque la transition associee fait quitter et entrer de nouveau dans 
l'etat lumiere allumee. 

3. Le mode chronometre s'appuie sur l'instance de Timer chrono. Chaque fois que Ton entre 
en mode chronometre, 1'afficheur est lie a l'instance de Timer chrono. 

Le chronometre est initialise a zero la premiere fois que Yon entre dans cet etat. Ce fonc- 
tionnement est modelise par la transition partant de l'etat historique, qui est la transition 
par defaut (portant Taction chrono. set(O)) utilisee uniquement la premiere fois que Ton 
penetre dans cette region. Celle-ci a ensuite deux sous-etats, selon que le chronometre est 
lance ou arrete. Si on la quitte et qu'on la retrouve ensuite, le dernier etat visite est atteint, 
ce qui represente bien le mecanisme de reprise decrit dans l'enonce. 

L'evenement note s-s correspond a la pression sur le bouton start-stop. Le point d'entree 
de cet etat composite mene directement a l'etat historique. L'absence de pseudo-etat 
initial est compensee par la presence d'un etat historique qui permet d'entrer dans 
la region. Un pseudo-etat final est egalement inutile puisque les transitions quittant cette 
region touchent la frontiere de l'etat et sont done franchissables depuis les deux etats 
stoppe et lance. 
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Figure 4.25 

Le mode 
chronometre. 



mode chrono 
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4. Le mode reglage a trois sous-etats representant le reglage de l'heure, des minutes et des 
secondes. A Fentree dans cette region, l'afficheur est lie au Timer time representant 
l'heure courante. 

Les actions do/ sont continues et durent tant que Ton reste dans Fetat, mais sont inter- 
rompues par une transition qui le quitte. Les methodes increment et reset incrementent 
ou remettent a zero le champ mentionne. 



Figure 4.26 
Le mode reglage. 
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EXERCICE 4 MODELISATION DE LA SOCKET TCP 



Cet exercice recapitulatif aborde la modelisation d'une socket de communication en mode 
connecte utilisant le protocole TCP {Transfer Control Protocol). Les etats utilises dans cette 
modelisation sont ceux affiches par la commande standard netstat et specifies dans la norme 
IEEE. Cet exercice correspond done a la modelisation d'un protocole reel. Ne soyez pas 
deroute par la complexite apparente du sujet : le passage des diagrammes de sequence pro- 
poses aux diagrammes d'etats-transitions est relativement direct. 
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Enonce 



Figure 4.27 

Ouverture de 
connexion TCP. 



Les sockets sont des points extremes de communication bidirectionnels : c'est une interface 
standardised, implemented sur quasiment toutes les plates-formes de facon homogene, 
pour permettre la portability d'applications interagissant a travers un reseau. 

Le modele offert pour l'utilisation de sockets TCP est de type client- serveur : 

• Le serveur offre un service aux clients, sur un numero de port bien connu (80 pour 
HTTP par exemple). II ouvre pour cela une socket qu'il place dans l'etat LISTEN 
(ecoute) et attend les requetes de client. 

• Le client est l'utilisateur du service. II ouvre une socket et demande la connexion au 
serveur, en fournissant l'adresse du service souhaite (par exemple : nom.de.serveur.fr:80). 

Si, a l'adresse specified, un serveur est bien en attente, une connexion entre le client et le 
serveur est etablie. 

Le diagramme de sequence de la figure 4.27 represente les etapes de cette ouverture de 
connexion. Les rectangles arrondis sur la ligne de vie donnent l'etat de l'instance de socket 
concerned. Les messages provenant de la bordure du cadre representent les messages pro- 
venant de l'application. Les messages (ou frames) SYN sont un des types de messages de 
controle du protocole TCP. Les trames ACK correspondent a des acquittements. Chaque 
trame TCP porte un numero de sequence, qui permet de gerer les pertes de trames et les 
acquittements. Toute trame peut porter, en plus de sa valeur propre, un acquittement 
encapsule dans le meme objet (piggy-back), pour des questions d'efficacite. 
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Une fois la connexion etablie, le protocole devient symetrique : les deux participants peu- 
vent lire et envoyer des messages. Vous ne modeliserez pas cette partie du protocole relati- 
vement complexe, qui assure la transmission sans pertes, duplications ou desequencement 
des messages, et la gestion transparente des congestions du reseau. 

La fin de connexion est initied par l'un des participants, quand son application appelle la 
methode close(). Pour que la connexion se termine proprement, un certain nombre de 
trames sont encore echangeds, comme le montre le schema presente a la figure 4.28. 
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Figure 4.28 

Fermeture de 
connexion TCP. 



sd Fermeture de 



connexion 



TCP 



7 



client:Socket { )-"*""" 



close() 



ESTABLISHED 



On note client et [\. 
serveur, mais cette 
partie du protocole 
est totalement 
symetrique 



La fin du timeout de 2 MSL 
(Maximum Segment Lifetime) 
ramene a l'etat CLOSED 



T 



""*-~<) server:Socket 
TT 




On dit de l'extremite notee client sur ce schema quelle fait une fermeture active, car elle 
initie la fin de connexion. Au contraire, Fextremite serveur subit une fermeture passive, a 
l'initiative de l'autre participant. A l'etat CLOSE_WAIT, les lectures de l'application sur la 
socket vont rendre le caractere de fin de fichier EOF, et Ton attend de l'application quelle 
appelle la methode closeQ pour une fermeture propre de la connexion. 

L'ensemble du protocole prevoit des problemes materiels tels qu'une interruption du 
reseau ou un crash d'un des participants : a chaque envoi d'une trame, on initialise une 
horloge, qui declenche la reemission de la trame si elle n'est pas acquittee a temps (on sup- 
pose que la trame s'est perdue sur le reseau) ou la fin de la connexion si la trame a deja ete 
emise trois fois (on suppose un crash reseau ou de l'autre participant). 

1. En vous basant sur les diagrammes de sequence fournis, elaborez un diagramme 
d'etats-transitions representant les etats d'une socket TCP. Vous distinguerez les etats 
correspondant a l'etat initial (CLOSED), a l'attente d'une connexion cote serveur, a 
l'attente d'etablissement de la connexion cote client, a la connexion etablie (_ESTA- 
BLISHED), et a la fermeture active et passive de la connexion. Certains de ces etats 
peuvent etre affines en sous-etats. 
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2. Une fermeture simultanee de la connexion se produit lorsque les deux participants 
demandent en meme temps cette fermeture (par appel de closeQ). Leurs trames de FIN 
se croisent et sont receptionnees alors que la socket est a l'etat FIN_WAIT_1 ou Ton 
attend habituellement un simple acquittement. Ce cas est decrit par le diagramme de 
sequence presente a la figure 4.29. 



Figure 4.29 

Fermeture 
simultanee de 
connexion TCP. 



sd Fermeture de connexion simultanee TCP 
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La fin du timeout de 2 MSL 
(Maximum Segment Lifetime) 
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C 



TIME WAIT 
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Modifiez le diagramme de la reponse a la question 1 pour permettre ce nouveau cas de 
figure. 



1 . Cet exercice modelisant un systeme reel est plus complet que les precedents. La solution 
proposee ici est une version simplifiee du protocole, inspiree du chapitre 18 de Fouvrage 
« TCP/IP illustre, volume 1 » de Stevens (1993, Addison Wesley). 

II faut decomposer le probleme en etapes. Dans ce but, elaborez dans un premier temps 
un diagramme ou n'apparaissent que les messages provenant de Fapplication et les etats 
proposes par l'enonce (voir figure 4.30). 
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Figure 4.30 

Etats d'une socket 
TCP du point de vue 
d'une application. 
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Ce premier diagramme donne une bonne vue d'ensemble du comportement de la socket. 
Sont mentionnes les informations et comportements principaux du protocole : une 
socket est initialement a l'etat CLOSED et peut etre sollicitee par un accept() (du cote 
serveur) ou un connect() (du cote client). La connexion est alors etablie (etat ESTA- 
BLISHED). La connexion peut se terminer soit de facon active, avec un appel de closeQ, 
soit de facon passive, si c'est l'autre participant qui met fin a la connexion. 

La solution proposee utilise un point de sortie alternatif pour representer ce dernier cas, 
au lieu de porter la trame FIN/ACK directement sur une transition de la bordure de l'etat 
ESTABLISHED a l'etat Fermeture passive. Ce parti pris assure une certaine coherence et 
permet de cacher sur ce diagramme toutes les trames de controle. Cela donne une vision 
de plus haut niveau du comportement. 

La fin nominale de la connexion correspond a l'etat final, atteint par une transition auto- 
matique depuis un des etats de fermeture. La transition sans etiquette qui ramene a l'etat 
CLOSED est alors franchie. 

Le mecanisme de timeout ramene a l'etat CLOSED et est franchissable depuis tout etat ou 
la connexion est engagee. 

Vient ensuite la description detaillee des etats recenses (figures 4.31 a 4.35), ce qui est 
relativement direct etant donne les diagrammes de sequence proposes. Sont omis sur ces 
diagrammes les numeros de sequence des messages. 
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Figure 4.31 

Cote serveur, 
attente d'un client. 
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Figure 4.32 

Cote client, etapes 
de la connexion. 



connexion au serveur 



/SYN 



SYN_SENT 



SYN.ACK / ACK 



Figure 4.33 

Symetrique, 
phase connectee 
d'echanges 
de donnees. 
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Figure 4.34 

Fermeture active, 
a I'initiative de 
('application. 
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Fermeture passive, 
suite a une 
demande de I'autre 
participant. 



fermeture passive 



> 

CLOSE_WAIT 


close()/FIN 


3» 


-< 





LAST_ACK 



ACK/ 



<§> 



Diagramme d'etats-transitions 153 



2. L'ajout de ce nouveau scenario se traduit par l'introduction d'une nouvelle transition 
depuis l'etat FIN_WAIT_L Le schema d' ensemble decrivant les etats n'est pas trans- 
forme : seul le comportement interne de l'etat composite fermeture active est modifie 
(figure 4.36). 
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La bonne modularity de la description precedemment elaboree permet de limiter le 
nombre et la portee des modifications necessaires pour prendre en compte ce nouveau 
scenario. 
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Diagramme 
d'activites 



1 . Action 

2. Activite 160 

3. Flot de controle 161 

4. Mecanismes avarices 171 

Problemes et exercices 

1 . Programmation en activites 1 77 

2. Vente en ligne 1 78 

3. Algorithmique 179 

4. Videoclub 182 

5. Cache d'operations 1 83 




Les diagrammes d'activites permettent de specifier des 
traitements a priori sequentiels. lis offrent un pouvoir 
d'expression tres proche des langages de programmation 
objet : specification des actions de base (declaration 
de variables, affectation...), structures de controle 
(conditionnelles, boucles), ainsi que les instructions 
particulieres d la programmation orientee objet (appels 
d'operations, exceptions...), lis sont done bien adaptes 
d la specification detaillee des traitements en phase de 
realisation. On peutaussi les utiliserdefacon plus informelle 
pour decrire des enchamements d'actions de haut niveau, 
en particulier pour la description detaillee des cas 
d'utilisation. 
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□ Action 



Les modeles servent d'abord a expliquer le fonctionnement d'un systeme, en fournissant 
une vision abstraite de ses comportements. Cependant, UML 2 a vocation a aller au-dela 
d'une simple description informelle, en fournissant la possibilite de decrire un systeme a un 
niveau de details qui permette son execution. Cela s'inscrit dans le cadre du MDA (Model 
Driven Architecture), mis au point par l'OMG, qui propose de centrer le developpement des 
systemes au niveau de leur modele. 

A terme, l'objectif est de fournir un langage de specification qui permette de se detacher des 
langages de programmation classiques : les developpeurs de demain pourront utiliser UML 
pour developper leur systeme sans jamais descendre jusqu'au niveau de langages de pro- 
grammation tels que Java, C++. 

Pour cela, UML doit etre dote de mecanismes offrant la precision d'un langage de program- 
mation au niveau de la description de l'effet des actions. Comme UML se veut universel, 
aucune syntaxe concrete n'est proposee dans la norme pour decrire les actions : c'est a la 
charge des outils d'en definir une ou d'utiliser la syntaxe d'un langage de programmation 
existant. Cependant, UML propose une definition des instructions de base qui constituent 
le langage oriente objet : c'est la description des actions UML. 

Sans aller dans les details de la definition, nous presentons ici les grandes categories 
d' actions que propose la norme, et donnons des exemples concrets d'instructions offrant en 
C++ ou Java la meme semantique. 

1 . 1 Gestion des appels de procedure 



Ces actions de communication gerent le passage et le retour de parametres et les mecanis- 
mes d'appels d'operations synchrones et asynchrones. 

Appel synchrone 

Les actions de type call correspondent a des appels de procedure ou de methode. 

Dans les deux cas, il est possible de specifier des arguments et d'obtenir des valeurs en retour. 
Ce type d'appel est bloquant : l'appelant attend la reponse de l'appele avant de continuer 
son execution. 

Call operation correspond a l'appel d'une operation sur un classeur. Call behavior correspond 
a l'invocation d'un comportement specifie a l'aide d'un diagramme UML, par exemple un 
diagramme d'activites ou d'interactions. Cela offre la possibilite, dans les diagrammes 
d'activites, de directement referer a d'autres types de diagrammes. Vous pouvez done utili- 
ser un diagramme de sequence par exemple (imbrique dans un diagramme d'activites) pour 
illustrer le comportement d'une activite, et reciproquement. 

Les actions accept call et reply peuvent etre utilisees du cote recepteur pour decomposer 
la reception de l'appel. Reply correspond precisement au return des langages de program- 
mation. 



EXEMPLE L'invocation d'une methode, ou d'une procedure plus complexe (un autre programme par 

exemple), correspond d une instance de call. 

Pour decrire un traitement recursif, il faut utiliser une action call behavior pour re-invoquer le 
comportement en cours de description. 
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Appel asynchrone 

Les appels asynchrones de type send correspondent a des envois de messages asynchrones : 
Fappelant poursuit son execution sans attendre que l'entite cible ait bien recu le message. 

Ce type d' appel est bien adapte a la modelisation de systemes materiels (communications 
sur un bus, interruptions d'entree/sortie avec send signal) ou de protocoles de communica- 
tion particuliers (UDP dans le domaine Internet, ou MPI dans le contexte multiprocesseur 
avec send object). 

Le broadcast signal permet d'emettre vers plusieurs destinataires a la fois, une possibility 
rarement offerte par les langages de programmation. 

L' action symetrique cote recepteur est accept event, qui permet la reception d'un signal. 



EXEMPLE La semantique d'un appel dans les langages objet (C++, Java) est toujours synchrone (c'est- 

a-dire de type appel de procedure). Cependant, certains mecanismes de communication 
peuvent etre vus comme des appels asynchrones. 

En Java par exemple, la methode notifyO de la classe Object permet de signaler d un autre 
thread Java I'occurrence d'un evenement. Cet appel n'est pas bloquant : I'execution se pour- 
suit sans attendre la bonne reception de I'appel. L'autre thread n'en est informe qu'apres un 
delai, quand la machine virtuelle I'elit pour s'executer. 

Evenements particuliers 

L' action raise exception permet de lever une exception au cours d'un traitement. 

Une exception est un element important de l'approche orientee objet ; elle permet de traiter 
des cas particuliers. Le comportement complet associe a la gestion des exceptions est decrit 
a la section 4.2 de ce chapitre. 



EXEMPLE Le mot-cle standard throw (en Java et en C++) correspond precisement d la semantique d'une 

action raise exception. 

Un time event est un evenement temporel declenche apres l'ecoulement d'une certaine 
duree (specifiee librement). On distingue graphiquement les actions associees a une com- 
munication : send signal, accept event et accept time event. Cela permet de mieux mettre en 
valeur les echanges entre les diagrammes de la specification. 



Figure 5.1 
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1 .2 Manipulation des variables 



Les variables en UML sont toujours considerees comme des instances d'une classe : les 
actions proposees sur les variables correspondent done a des acces sur un objet. On retrouve 
ici toutes les operations usuelles des langages de programmation. 

Acces et mise d jour 

Les variables UML sont en principe des objets. Cependant, nous incluons aussi les types de 
base (int, float, boolean, string), qui ne sont pas a proprement parler des objets parmi 
les types de variables. Cela suppose que Foutillage permettra de les gerer par des profils ou 
des bibliotheques. Par exemple, Foperation i++ doit se resoudre comme un appel de la 
methode ++ sur Fobjet i de la classe Int. 

UML propose en outre des variables dites « multivaluees », qui correspondent a des collec- 
tions, triees ou non. Leur introduction permet de faire mieux abstraction de l'implemen- 
tation : elles peuvent representer une liste, un tableau, une table associative, etc. de facon 
homogene. En Java, Finterface Collection correspond bien a la notion de variable multi- 
valued 

La lecture d'une variable par read variable permet d'acceder a son contenu. L'action clear 
variable permet de reinitialiser une variable. Si elle est multivaluee, clear la vide de ses 
valeurs. Pour les variables monovaluees, clear n'a pas d'equivalent direct en programmation 
objet, si ce n'est Faffectation d'un objet construit par defaut a la variable. 

Les actions d'ecriture permettent non seulement d'affecter une valeur a une variable, mais 
egalement d'ajouter ou de supprimer des valeurs a une variable multivaluee (type collection 
d'objets). En consequence, les actions d'ecriture se declinent en add variable value et remove 
variable value. 

Enfin, une action value specification correspond a la definition d'une constante ou d'un 
litteral (la valeur 3, le caractere 'a', la chaine "hello"). 

Manipulations des objets 

Pour la manipulation des objets, UML offre les actions de base associees a la programma- 
tion objet. 

Create object et destroy object permettent la creation et la destruction d'instances d'objets. 
II est ainsi possible de creer et de detruire des variables locales, ainsi que des variables de 
portee plus grande (attribut statique de classe, par exemple). 

Une fois Fobjet construit, Faeces a ses champs se fait a Faide d'actions read structural feature, 
qui permettent d'acceder a ses attributs comme a ses operations. Elles correspondent a la 
notation pointee (monObjet.attributl.laMethodeQ) des langages de programmation. 

Toute action qui se deroule dans un contexte d'instance (non statique) peut acceder a Fins- 
tance courante par read self (self correspond a Fidentite de Fobjet courant, note this en Java 
et en C++, par exemple). 

Enfin, des actions permettent de modifier le type d'un objet (reclassify object) ou de tester 
l'appartenance d'un objet a un type donne (is classified). 

En general, il n'est possible de reclassifier un objet qu'en respectant Farbre d'heritage : typer 
une instance de classe derivee en instance de classe de base est une operation toujours legale. 
La reciproque est fausse. 
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EXEMPLE Ces mecanismes de typage sont frequemment utilises dans ('implementation d'operateurs de 

comparaison definis au niveau d'une classe de base. 

public boolean equals (Object o) { 

if ( ! (o instanceof MaClasse) ) { 
return false; 
} else { 

MaClasse a = (MaClasse) o; 

return this.attribl .equals(a.attrib1 ) ; 

} 

} 



#include <typeinfo> 
bool operator== (const 
if ( typeid(o) != 
return false; 
} else { 

MaClasse * 
return this 



ClasseBase & o) const { 
typeid(MaClasse) ) { 



pa = (MaClasse *) &o; 
>attrib1 == pa->attrib1 ; 



Gestion des pointeurs et references 

UML integre la notion de pointeur, sous le nom « link ». Les actions associees permettent de 
manipuler directement une reference a un objet (ou pointeur). On declare, en general, un 
objet de type reference avec create link object et on lui affecte ensuite des valeurs avec create 
link, destroy link correspond a un clear et ne detruit pas F objet link mais bien le lien vers 
Fobjet qu'il reference. L'acces a la valeur referencee par le lien est assure par une action read 
link. 

L'arithmetique des pointeurs n'est pas totalement prise en charge, mais Taction test identity 
permet de comparer des references. Cette action teste l'identite (egalite physique en 
memoire) de deux objets. Cela revient a comparer les adresses des objets. 



EXEMPLE En Java, tout objet est manipule par reference ; il n'existe pas de facon particuliere de lire la 

valeur associee d la reference : les deux notions sont confondues. 

En C++, un pointeur est explicitement manipulable. Une instance d'objet ou une reference sur 
objet se manipulent de la mime facon. L'operateur etoile (*) de dereferencement correspond 
a la notion de read link d'UML. 



Modification du modele de classes 

La modification du modele de classes (ajout d'attributs ou d'operations) est assuree par des 
actions de type add ou remove structural feature. Ces actions ont peu d'interet dans le cadre 
d'une utilisation usuelie de langage objet. L'objectif est de modifier en cours d'execution la 
structure d'une classe. 



EXEMPLE Smalltalk et Python sont deux exemples de langages objet qui permettent ce niveau de reflec- 

tivite en cours d'execution. 

En Java, ce type d'operation n'est pris en charge qu'au niveau bytecode, pas directement au 
niveau des fonctionnalites standard du langage. Certaines bibliotheques specialisees offrent 
cependant une interface de haut niveau pour realiser ces operations. Elles sont utilisees dans 
des approches reflexives, comme le tissage d'aspect [Aspect Oriented Programming). 
Le modele de compilation statique de C++ ne permet pas ce type d'operation, apres la decla- 
ration d'une classe. 
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1 .3 Action opaque 



Une action opaque n'a pas de semantique ou de contrainte particuliere, et n'a done pas un 
sens defini par UML. C'est done aux outils de savoir interpreter ce type d'action, qui 
depasse le cadre d'UML, limite aux actions precitees dans cette section. 

Les actions opaques permettent l'integration de librairies ou routines de traitements exis- 
tants. Elles peuvent egalement correspondre a des traitements qui n'ont simplement pas ete 
modelises. 

Parmi les actions opaques figurent egalement les operations sur les types machine de base : 
arithmetique entiere et flottante, masques et vecteur de bits, etc. Bien que communes a la 
majorite des langages de programmation, elles ne sont pas standardises en UML. 

1 .4 UML 2 ET LES ACTIONS 



UML definit des actions qui couvrent les instructions elementaires d'un langage de pro- 
grammation, mais ne propose pas de mecanismes pour exprimer des boucles, des condi- 
tionnelles, des blocs d'actions consecutives. II s'agit la d'une evolution importante d'UML 2 
par rapport aux versions precedentes d'UML 1.x, qui integraient ces mecanismes dans les 
actions. 

En UML 2, la description de la structuration des actions est laissee aux activites. Ainsi, le 
modele est plus clair et mieux decouple. Les activites englobent les actions et offrent des 
mecanismes pour exprimer clairement le cheminement du flot de controle. 

On peut cependant regretter l'absence d'operations explicitement defmies sur les types de 
base habituels (operations arithmetiques, par exemple). On peut esperer qu'un profil UML 
standardise verra bientot le jour pour prendre en charge ces types. 



0 Activite 

2.1 MODELISATION DES TRAITEMENTS 



Les actions elementaires sont decrites separement en UML. Les traitements complets sont 
decrits par des activites, qui offrent une maniere concise et sans ambigu'ite de presenter 
graphiquement un traitement sequentiel, avec tout l'arsenal propose par un langage de pro- 
grammation oriente objet (actions de base, boucles et conditionnelles, appels de methode, 
gestion des exceptions. . .). 

Les activites donnent done une description complete des traitements associes a des compor- 
tements au sens interaction d'UML. On les utilise couramment pour etiqueter les autres 
diagrammes (traitements associes aux messages des diagrammes de sequence, transitions 
des diagrammes d'etats-transitions) ou pour decrire l'implementation d'une operation 
d'un classeur. 

Les diagrammes d'activites sont relativement proches des diagrammes d'etats-transitions 
dans leur presentation, mais leur interpretation est sensiblement differente. En particulier, 
ils offrent un support pour l'expression de mecanismes concurrents, mais ce n'est pas la leur 
fonction premiere. 
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2.2 Une vision transversale, decouplee de la vision structurelle 
classes/composants 



La vision des diagrammes d'etats-transitions est en effet orientee vers des systemes reactifs, 
les transitions etant declenchees par la reception de sollicitations, sans que la source de 
Fevenement soit specifiee. Cela est bien adapte aux systemes concurrents, oil chaque com- 
posant a son propre flot de controle, par exemple les systemes bases sur des objets actifs ou 
les systemes materiels. Leur avantage est de specifier sans ambigu'ite l'effet de toute action 
sur le composant, sans a priori sur le comportement de Fenvironnement. 

Mais ils ne donnent pas une vision satisfaisante d'un traitement faisant intervenir plusieurs 
composants ou classes, et doivent etre completes par des scenarios d'interaction, usuelle- 
ment decrits a l'aide de diagrammes de sequence. Au contraire, les diagrammes d'activites 
permettent une description centree sur le traitement, en s'affranchissant (partiellement) de 
la structuration de l'application en classeurs. 

2.3 Programmation structuree 



Un flot de controle est associe a chaque processus ou thread d'une application : il represente 
le curseur d'execution {program counter) qui execute les instructions d'un programme. A 
un instant donne, il execute une certaine instruction ; le choix de Finstruction suivante a 
executer est determine par les structures de controle du langage {if /else, for, while, switch/ 
case...). Les activites capturent de facon graphique ce comportement a priori sequentiel de 
F execution. 

En mettant Faccent sur le traitement, la vision des diagrammes d'activites se rapproche des 
langages de programmation proceduraux type C ou Pascal. Une activite se comporte par 
bien des points de vue comme une procedure, possedant des arguments en entree et des 
valeurs de sortie et pouvant causer des effets de bord sur les variables accessibles depuis leur 
contexte. II est possible, dans un premier temps, de raisonner purement sur les traitements 
et, lors d'une phase de conception detaillee, d'affecter les differentes activites recensees a des 
classeurs du systeme. 



0 Flot de controle 

3 . 1 Activite et transition 



La vision des diagrammes d'activites est centree sur les flots de controle. On y trouve deux 
elements fondamentaux : 

• Les activites, representees par un rectangle aux coins arrondis, decrivent un traitement. 
Le flot de controle reste dans Factivite jusqu'a ce que les traitements soient termines. On 
peut definir des variables locales a une activite et manipuler les variables accessibles 
depuis le contexte de Factivite (classe contenante en particulier). Les activites peuvent 
etre imbriquees hierarchiquement : on parle alors d'activites composites. 
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Les transitions, representees par des fleches pleines qui connectent les activites entre 
elles, sont declenchees des que l'activite source est terminee et determinent la prochaine 
activite a declencher. Contrairement aux activites, les transitions sont franchies de 
maniere atomique, en principe sans duree perceptible. 



EXEMPLE La commande 

Cet exemple fait apparaTtre un certain nombre de possibilites des diagrammes d'activites. On 
y trouve la description d'un traitement Passer Commande. Les trois cadres, appeles « lignes 
d'eau », permettent de situer les actions par rapport aux entites du systeme : on identifie trois 
intervenants dans ce traitement, d savoir le client, le service comptable et le service livraison. 
Les cercles noirs pleins designent un etat initial, utilise pour debuter le traitement. Les cercles 
contenant un point noir designent des etats finaux, ou le traitement est considere comme 
termine. 

L'action se deroule comme suit : le client commence par passer une commande, ce qui donne 
lieu d I'elaboration d'un devis par le service comptable. L'elaboration du devis estelle-meme 
decomposee en deux sous-activites : verifier la disponibilite des produits commandes et calcu- 
ler le prix de la commande. 

Pour mieux faire apparaTtre la transmission du devis au client, on fait figurer un noeud 
d'objets. Cela represente un flux de donnees echangees entre le service comptable et le 
client. Devis est le nom d'une classe du systeme : les flots de donnees sont types. Le client 
peut ensuite decider de modifier sa commande (retour dans l'activite initiale Passer com- 
mande), de I'annuler (passage dans I'etat final, signifiant la fin de ce traitement), ou de vali- 
der le devis. 

S'il valide, deux actions peuvent etre engagees en parallele : la preparation de la com- 
mande par le service livraison et le traitement de la facturation et du paiement. Le service 
comptable cree une facture qu'il envoie au client (I'objet facture transmis est alors dans I'etat 
emise). Celui-ci effectue le paiement et renvoie la facture (qui se trouve d present dans 
I'etat reglee). 

Quand la commande est prete et le paiement du client confirme (synchronisation par rendez- 
vous de ces deux activites), la commande est livree au client et le traitement s'acheve. 



Notation 

Une activite UML est representee par un rectangle aux coins arrondis (figure 5.3) et 
contient la description textuelle des actions de base qu'elle realise, ou simplement son nom 
si le niveau de specification n'est pas encore assez precis pour detailler les actions. Aucune 
syntaxe specifique n'est proposee dans la norme pour I'expression de ces actions : on 
utilise le plus souvent une syntaxe proche d'un langage de programmation ou, d defaut, 
du pseudo-code. Les activites sont liees par des transitions representees par des arcs orien- 
tes pouvant porter des gardes, qui represented le cheminement du flot de controle de 
I'application. 

Certaines actions sont distinguees par un graphisme particulier (figure 5.1). 

. I 
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Figure 5.2 
La commande. 
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Figure 5.3 

Notation 
des activites. 
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3.2 Structures de controle 



Structure de controle conditionnelle 

La facon la plus naturelle d'exprimer les conditions est d'utiliser des transitions munies 
d'une garde : de telles transitions ne peuvent etre empruntees que si la garde s'evalue a vrai. 
Une garde est un test pouvant faire intervenir les variables accessibles depuis le contexte de 
l'activite. En principe, une garde n'a pas d'effets de bord, car elle peut etre evaluee plusieurs 
fois. 

On peut ajouter une garde a toute transition d'un diagramme d'activites. Elle est notee 
entre crochets. Si plusieurs transitions sont simultanement franchissables, le choix de la 
transition empruntee est indeterministe ; en general, il est done preferable de s'assurer 
qu'une seule transition a la fois est franchissable. On peut utiliser une clause [else] dans une 
garde, qui est validee si et seulement si toutes les autres gardes des transitions ayant la meme 
source sont fausses. 

Les gardes peuvent porter sur des transitions ayant pour source une activite. Cependant, si 
Ton veut mieux mettre en valeur le branchement conditionnel, on peut utiliser un point de 
jonction, represente par un losange. Les points de jonction expriment un aiguillage du flot 
de controle : ils peuvent avoir plusieurs transitions en entree comme en sortie. lis ont la 
semantique d'un if/endif ou d'un switch/case des langages de programmation. Ce sont des 
etats dits « de controle » (comme les etats initiaux ou finaux), dans lesquels le flot de 
controle ne s'attarde pas : le franchissement d'une transition entre une activite et la suivante 
est globalement atomique, meme si Ton traverse des points de jonction. 



Exemple Le distributee de billets 

Cet exemple illustre differentes representations des alternatives. Apres la verification preli- 
minaire, deux activites sont potentiellement declenchees : la restitution de la carte si la verifi- 
cation echoue ou l'activite taper PIN (Personal Identification Number) sinon. Apres le controle 
du code PIN, on trouve trois alternatives, connectees d un point de decision ; une seule 
d'entre elles sera utilisee. Enfin, la note portant le mot-cle « decisionlnput » indique que les 
gardes sur les transitions apres le point de choix comparent la variable automation accordee 
a oui ou non. 

Cet exemple est modelise d un niveau relativement eleve d'abstraction, les actions etant expri- 
mees en langage naturel. II decrit de facon concise un comportement relativement complexe. 
Ce niveau de description conceptuelle est bien adapte a la specification detaillee des cas 
d'utilisation, car il resume de facon synthetique plusieurs scenarios. 
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Figure 5.4 

Le distributeur 
automatique 
de banque. 



Chapitre 



«external» 



Client 



Inserer Carte 



Taper PIN 



Saisir montant 



Verification preliminaire 



[echec] 



[else] 



7 



[Code faux et essai < 3] 



Controler code 




[else] 



Avaler Carte 



Obtenir Autorisation 



«decisionInput» 
Autorisation accordee 



[Code bon] 



[non] 




Restituer Carte 



Delivrer Billets 



EXEMPLE 



Les points de decision peuvent aussi modeliser la fin d'une alternative. On les appelle alors 
« points de debranchement ». 

Compter les mots, les lignes, les caracteres 

L'exemple de la figure 5.5 illustre la possibility de representer le flot de controle d'un pro- 
gramme d I'aide d'un diagramme d'activites. L'activite appelee wc realise le comportement de 
I'outil Unix wc (word count). On utilise ici la notation frame (qui sert aussi dans les diagram- 
mes de sequence) pour la representer, et le stereotype activity. 

On declare les variables locales de l'activite, nc, nw, nl, qui servent d compter respectivement 
le nombre de caracteres, de mots et de lignes de I'entree. On utilise une variable c de type 
char pour stocker le dernier caractere lu de I'entree (par la fonction getchar()). L'etat cou- 
rant de la lecture (dans mot ou hors mot) est represents par une variable booleenne inWord. 
On suppose ici que print, getchar, isWhitespace, I'operation d'increment ++ sont fournies 
(sous la forme d'actions opaques). 

Comme on le voit sur cet exemple, les diagrammes d'activites d'un niveau de specification 
detaillee permettent d'atteindre le pouvoir d'expression de langages de programmation 
classiques. 
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Figure 5.5 

Compter les lignes, 
les mots et les 
caracteres. 
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Activite structuree 

La norme prevoit egalement des activites dites « structurees », qui utilisent les structures de 
controle usuelles (conditionnelles et boucle) a travers une syntaxe qui depend de l'outil. La 
syntaxe precise de ces annotations, comme celle des actions de base, n'est done pas definie 
dans la norme : on utilise du pseudo-code ou la syntaxe d'un langage de programmation. 



EXEMPLE Avec une syntaxe C++, on decrit une activite contenant une boucle (le calcul du prix total 

d'une facture) et une activite contenant une conditionnelle (une implementation possible de 
isWhitespace() de I'exemple precedent). Les arguments et valeurs de retour sont decrits d 
I'aide de pins, presentes en detail d la section 3.4. 



Fiour© 5.6 
Activite structuree. 
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total=0; 

for (int i=lignes.size0-l ; i >= 0 ; i— ) 

total += lignes[i].prixUnitaire * lignes[i].quantite 



lignes : vector<ligneCommande> 



7 \ 



if(c= llc== \t llc== \n ) 
return true; 

else 

return false; 



total: float 



bool 



Ce type d'activite est fourni par commodite, mais son utilisation rend peu visible le chemi- 
nement du flot de controle. 



3.3 Activite et classeur 



Les activites peuvent etre utilisees pour des descriptions de differents niveaux de details, de 
la plus elementaire (description conceptuelle d'un comportement par exemple) a la plus 
fouillee, faisant alors intervenir des actions UML pour etre a la hauteur de ce que permet un 
langage de programmation. 

Une de leurs utilisations principales est de decrire l'effet d'operations de classeur. Les activi- 
tes peuvent, dans un premier temps, ne pas avoir un contexte bien defini. C'est le cas dans 
I'exemple du distributeur de banque : le systeme complet du DAB n'etant pas encore 
decompose en sous-elements, seules les activites afferentes au client ont ete placees sur une 
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ligne d'eau. Une description plus detaillee necessiterait sans doute de decomposer plus fine- 
ment les actions, en vue de representer plus explicitement les appels d'operation sur les 
composants du systeme (lecteur de cartes, serveur d' authentication, imprimante pour le 
ticket...). Sur le diagramme de la figure 5.4, le mot-cle extern, sis au-dessus de la partition 
du client, indique que ce dernier n'est pas un element du systeme en cours de conception. 

Les lignes d'eau (ou partitions) permettent d'attribuer les activites a des elements parti- 
culiers du modele. Une partition peut elle-meme etre decomposed en sous-partitions. La 
liste suivante reunit les types standard d'une etiquette de partition : 

• Classeur. Les activites de la partition sont sous la responsabilite du classeur indique : le 
contexte de l'activite est done celui du classeur concerne. Lappel effectif de l'activite dans 
un scenario de comportement doit se faire sur une instance du classeur. 

• Instance. En plus des contraintes imposees par la notion de classeur, l'appel effectif doit 
se faire sur l'instance citee. 

• Attribut et valeur. Ce cas est assez different des precedents. On a toujours au moins deux 
niveaux de partition : la partition englobante donne le nom de Fattribut concerne, et ses 
sous-partitions specinent une valeur de l'attribut. 



EXEMPLE Utilisation de partitions 

II est possible d'affiner le modele de la commande presente precedemment en specifiant plus 
finement le type des lignes d'eau. II s'agit d'indiquer, d'une part, que les activites du service 
comptable sont rattachees d une instance qui a, pour l'attribut HbelleService de type Service, 
la valeur Service Comptable et, d'autre part, que le client ne fait pas partie integrante du 
systeme etudie. 



Figure 5.7 
Lignes d'eau. 
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Les activites peuvent appartenir a plusieurs partitions, si ces dernieres fournissent une 
information qui n'est pas conflictuelle (par exemple, une activite donnee ne peut appartenir 
qua un unique classeur). On peut meme cumuler graphiquement des partitions en les 
placant horizontalement et verticalement. 



EXEMPLE Partitions multidimensionnelles 

La version simplifiee de la commande presentee d la figure 5.8 exprime que la reception des 
commandes se fait au siege social d Paris, que la validation du paiement est realisee par le 
service comptable de Roubaix, et que les commandes sont preparees et livrees par un service 
livraison situe egalement d Roubaix. ['utilisation de partitions multidimensionnelles ne facilite 
pas la lisibilite des diagrammes. 
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Figure 5.8 
Partitions 

multidimensionnelles. 
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II est possible de specifier la partition a laquelle appartient une activite directement dans 
l'etiquette de l'activite, entre parentheses. Si une activite est ainsi etiquetee, cette informa- 
tion prevaut sur Fappartenance eventuelle a une partition graphiquement representee. 



EXEMPLE 



Partition explicite 

Cette notation est moins encombrante graphiquement, mais met moins bien en valeur I'appar- 
tenance de groupes d'activites d un meme conteneur. 



Figure 5.9 
Partition explicite. 
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3.4 Argument et valeur retournee 



Si les diagrammes d'activites presentes jusqu'ici montrent bien le comportement du flot de 
controle, le flot de donnees n'apparait pas clairement. Or, c'est un element essentiel des 
traitements : si une activite est bien adaptee a la description d'une operation d'un classeur, 
il faut un moyen de specifier les arguments et valeurs de retour de l'operation. C'est le role 
des pins, des nceuds et des flots d'objets associes. 
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Pin 

Pour specifier les valeurs passees en argument a une activite et les valeurs de retour, on uti- 
lise des pins. Un pin represente un point de connexion pour une action : Faction ne peut 
debuter que si Ton affecte une valeur a chacun de ses pins d'entree ; quand elle se termine, 
une valeur doit etre affectee a chacun de ses pins de sortie. 

La semantique associee est celle des langages de programmation usuels : les valeurs sont 
passees par copie, une modification des valeurs d'entree au cours du traitement de Taction 
n'est visible qua Finterieur de Factivite. 

Un pin est represente par un petit carre attache a la bordure d'une activite. II est type et 
eventuellement nomme. II peut contenir des fleches indiquant sa direction (entree ou 
sortie) si cela n'est pas determine par le contexte d'utilisation de Factivite. 



Exemple Utilisation de pins 

Soit Factivite representant I'operation produit entre deux entiers a et b. On utilise un pin pour 
representer chaque argument, et un pin de sortie pour representer la valeur retournee. 

Figure 5.10 

a:int 

Representation 

de pins. b:int 



> 



Les valeurs associees aux pins peuvent etre utilisees comme les variables du contexte dans les 
traitements associes a Factivite. Introduisez un pin par argument du traitement. Vous pou- 
vez ainsi de definir des traitements parametres, ce qui manquait cruellement aux versions 
precedentes d'UML. 

Les pins servent egalement a representer des mecanismes d'exceptions. Un triangle signale 
un pin d'exception. 



EXEMPLE Representation des pins d'exceptions 

La methode elementAt de la classe Vector de la librairie standard Java renvoie I'element du 
vecteur situe a I'indice donne en argument, mais peut echouer si cet indice est negatif ou 
au-deld de la taille courante du vecteur. On emet alors une exception. 



Figure 5.1 1 
Pin d'exception. 
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Vous avez done les moyens de representer graphiquement une operation d'un classeur, avec 
sa signature complete : arguments, type de retour et exceptions potentiellement levees. Vous 
avez en outre la possibilite de definir une activite comme appartenant a une classe. En 
conclusion, les mecanismes essentiels de la programmation orientee objet sont presents 
dans les diagrammes d'activites. 

Noeud et flot d'objets 

Un flot d'objets permet de passer des donnees d'une activite a une autre. De fait, un arc qui a 
pour origine et destination un pin correspond a un flot d'objets. Le type du pin recepteur doit 
etre parent (au sens heritage) du type du pin emetteur ; le flot d'objets est lui-meme type. 

II est possible de mieux mettre en valeur les donnees par Futilisation d'un noeud d'objets 
detache d'une activite particuliere. Un noeud d'objets, represente par un rectangle, est un 
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conteneur type qui permet le transit des donnees. II sert egalement de stockage : il peut con- 
tenir plusieurs instances d'objet, a la maniere d'un tampon (buffer). 

Un nceud d'objets (ou un pin) peut imposer des contraintes, que doivent verifier les objets 
qu'il contient. Elles sont exprimees sous la forme d'invariants d'etat, notes entre crochets. 

Implicitement, tout arc ayant pour source ou destination un noeud d'objets est un flot 
d'objets plutot qu'un flot de controle. Un flot d'objets peut porter une etiquette mention- 
nant deux annotations particulieres : 

• transformation indique une interpretation particuliere de la donnee transmise par le flot. 

• selection indique l'ordre dans lequel les objets sont choisis dans le noeud pour le quitter. 
Une annotation de selection peut egalement figurer sur un noeud d'objets : l'ordre speci- 
fic est alors commun a tout arc ayant pour source ce noeud. 



Figure 5.1 2 
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Figure 5.1 3 

Annotations des 
flots de donnees 
et invariants d'etat. 
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Enfin, certains flots d'objets correspondent mieux a la notion de flot continu de donnees : 
ils portent 1' etiquette {stream} ou ont pour cible un pin de type {stream} (represents: par un 
carre noir plein). Le comportement usuel d'une activite consiste a « consommer » un objet 
sur chaque pin d'entree, a s'executer et a fournir une valeur sur chaque pin de sortie. Une 
activite peut cependant « consommer » (respectivement emettre) plusieurs donnees sur ses 
pins d'entree (respectivement de sortie) qui sont du type stream. 



EXEMPLE 



Filtres Unix 

La plupart des commandes standard Unix sont concues comme des filtres, qui lisent sur leur 
entree standard stdin et ecrivent sur leur sortie standard stdout. Le signalement des erreurs 
passe par un troisieme flux : stderr. II est possible de chaTner les commandes, ce qui permet 
de construire facilement des commandes plus puissantes. 
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□ Mecanismes avarices 

Les constructions presentees a la section 3 sont suffisantes pour la majorite des usages. 
Ce jeu d'elements de base constitue le coeur du formalisme des diagrammes d'activites. II 
est recommande de bien comprendre ces mecanismes avant d'aborder cette section, qui 
presente des concepts plus complexes proposes par les diagrammes d'activites. 

4.1 Concurrence 



La vocation premiere des diagrammes d'activites est de decrire des traitements a priori 
sequentiels : on ne debute l'activite apres une transition que lorsque celle qui la precede est 
terminee. 

Cependant, il est possible de decrire des mecanismes concurrents a l'aide de diagrammes 
d'activites. Cela ne signifie pas necessairement que l'implementation est concurrente, mais 
plutot que les actions decrites ne sont pas liees par une dependance causale : l'ordre d'exe- 
cution n'a pas d'incidence sur le comportement global. 

Dans l'exemple de la commande presente a la section 3.1, Factivite preparer commande peut 
etre realisee avant ou apres l'activite etablir facture, ou meme simultanement. 

La gestion de la concurrence ajoute deux nouveaux elements graphiques aux diagrammes 
d'activites : 

• Les barres de synchronisation. Elles sont representees par une barre noire epaisse et 
courte. Plusieurs transitions peuvent avoir pour source ou pour cible une barre de syn- 
chronisation. Lorsque la barre de synchronisation a plusieurs transitions en sortie, on 
parle de transition de type fork, qui correspond a une duplication du flot de controle en 
plusieurs flots independants ; quand la barre de synchronisation est atteinte, un jeton de 
controle est produit sur chaque arc de sortie. Quand la barre de synchronisation a plu- 
sieurs transitions en entree, on parle de transition de type join, qui correspond a un 
rendez-vous entre des flots de controle ; la transition ne peut etre franchie que si un jeton 
de controle est present sur chacune de ses entrees. Pour plus de commodite, il est possible 
de fusionner des barres de synchronisation de type join et fork, et done d' avoir sur une 
meme barre plusieurs transitions entrantes et sortantes. Dans tous les cas, le franchis- 
sement des transitions se fait de maniere atomique, la barre de synchronisation ne stocke 
pas les jetons : ils restent dans les activites en amont jusqu'a ce que la transition puisse 
etre franchie. 

• Les noeuds de controle de type flow final. Ils sont represented par un cercle contenant une 
croix et correspondent a la fin de vie d'un jeton de controle. Un jeton de controle qui 
atteint un tel noeud est detruit. Les autres flots de controle ne sont pas affectes. Au 
contraire, si un flot de controle atteint un noeud de controle final, tous les autres flots 
de controle de l'activite sont interrompus et detruits. 



EXEMPLE Fabrication d'un produit manufacture 

Cet exemple montre une barre de synchronisation de type forkel des nceuds de controle flow 
final. II represente une procedure de fabrication d'un produit manufacture. Les pieces neces- 
saires d I'assemblage sont produites sequentiellement par l'activite Fournir piece. Des qu'une 
piece est prete, elle peut etre montee. 

Le franchissement de la barre de synchronisation produit deux jetons de controle : I'un realise 
l'activite Monter piece, I'autre s'occupe de fournir la piece suivante si toutes les pieces n'ont 
pas encore ete fournies. Quand il ne reste plus de piece d fournir, le flot se termine. L'activite 
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Monter piece peut avoir des durees variables ; chaque fois qu'elle se termine, on teste si le 
montage est termine ou non. Une fois la derniere piece montee, le produit est emballe et 
I'activite englobante se termine. 

Si ce diagramme suggere I'existence de concurrence, ce n'est Id qu'une possibility d'implemen- 
tation : un seul operateur physique peut realiser I'ensemble des activites (de facon sequentielle) 
sans devier de la semantique du modele. 
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Les barres de synchronisation permettent done d'exprimer que des actions peuvent debuter 
en parallele, alors que les transitions ordinaires des diagrammes d'activites imposent une 
execution sequentielle. Les transitions de type join imposent, au contraire, d'attendre la fin 
d'un ensemble d'activites avant de poursuivre F execution. 



4.2 Exceptions 



Les exceptions sont un concept important en programmation orientee objet : elles permet- 
tent d'interrompre un traitement quand une situation qui devie du traitement normal se 
produit et assurent une gestion plus propre des erreurs qui peuvent se produire au cours 
d'un traitement. 

Un exemple typique est la gestion de la division par zero dans une operation arithmetique : 
si Ton declare une operation float diviser (float dividende, float diviseur), comment signa- 
ler a l'appelant qu'une erreur de debordement se produit quand le diviseur vaut zero ? On 
ne peut utiliser une valeur de retour particuliere que l'appelant pourrait tester car toutes les 
valeurs de retour sont potentiellement valides. La solution preconisee est done de recourir a 
une exception, qui ne correspond pas a une valeur de retour de la signature normale de 
l'operation. L'appelant a alors le choix, quand il appelle l'operation diviser, de traiter 
l'exception ou de la laisser remonter a son propre appelant. Une exception qui n'est traitee a 
aucun niveau correspond a une faute du programme. Dans la plupart des langages orientes 
objet, elle induit la fin du processus ; en UML, le comportement n'est pas specifie, mais le 
modele est alors considere comme incomplet ou mal forme. 

Definition : gestion des exceptions 

Toute activite peut avoir un ou plusieurs pins d'exception (note par un triangle). La levee de 
l'exception se represente par une transition qui vise le pin d'exception, ou par une anno- 
tation textuelle, dans le cas d'activites structurees, dont la forme depend de I'outil utilise 
(mot-cle throw par exemple). 

Lorsqu'une exception est levee, I'execution de I'activite en cours est interrompue sans gene- 
rer de valeurs de sortie. A la place, un jeton de donnees representant l'exception est 
genere. Le mecanisme d'execution recherche alors un gestionnaire d'exception susceptible 
de traiter ce type d'exception ou une de ses classes parentes. On dit d'un gestionnaire 
d'exception (ou clause catch des langages de programmation) qu'il protege une activite. 
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Definition : gestion des exceptions [suite] 




On examine d'abord I'activite qui a donne lieu d la levee de T exception. Si un gestionnaire 
d'exception existe, il est invoque avec pour argument ladite exception. II doit avoir les 
memes pins de sortie, en nombre et en type, que le bloc qu'il protege. Un gestionnaire 
d'exception se represente par une activite ordinaire, munie d'un pin d'entree du type de 
I'exception qu'il gere, et liee au bloc (activite) qu'il protege par un arc en zigzag. 
Quand I'execution du gestionnaire se termine, I'execution se poursuit comme si I'activite 
protegee s'etait terminee normalement, avec les valeurs de sortie du gestionnaire en lieu et 
place de celles du bloc protege. II est inutile de faire figurer des transitions depuis I'activite 
representant le gestionnaire d'exception. 

Si I'activite qui a leve I'exception n'est pas protegee, I'exception interrompt I'activite englo- 
bante et un gestionnaire d'exception est recherche a ce niveau. Ce mecanisme de propa- 
gation se poursuit jusqu'd ce qu'un gestionnaire adapte soit trouve (ou que Ton quitte 
I'application). 



EXEMPLE Traitement des exceptions dans le calcul du produit d'une matrice par un vecteur 

Cet exemple montre un mecanisme de gestion d'exceptions. L'activite protegee calcule un pro- 
duit d'une matrice par un vecteur en deux etapes : on inverse d'abord la matrice argument m, 
puis on realise le produit par le vecteur argument v. 

L'inversion de matrice est susceptible de lever une exception si I'operation est impossible 
(discriminant nul par exemple). L'inversion et le produit sont susceptibles de provoquer un 
debordement de capacite de flottants. On protege I'ensemble du bloc par deux gestionnai- 
res d'exception distincts : selon I'exception levee, on fournit une constante (de type vecteur) 
differente. 

Dans tous les cas, Taction affkher vecteur est realisee d la fin du traitement. 
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Les exceptions sont des classeurs a part entiere et peuvent, a ce titre, porter des informations 
sous la forme d'attributs, et des operations. Vous pouvez egalement decrire des arbres 
d'heritage d'exceptions. Cela permet de specifier des messages detailles associes aux erreurs 
et des donnees supplementaires decrivant lesdites erreurs. Un gestionnaire d'exception 
specifie le type d'exception qu'il est capable de traiter : toute exception derivant de ce type 
est egalement traitee par un tel gestionnaire. 
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Exemple Specification des exceptions Java 

Cet extrait de la specification des exceptions Java illustre le fonctionnement des arbres d'heri- 
tage d'exceptions. Toutes les exceptions en Java derivent de la classe Exception du paque- 
tage java.lang ou de I'interface Throwable du meme paquetage. L'interface Throwable definit 
des operations permettant de determiner I'origine de I'exception, telles que printStackTrace, 
qui affiche les numeros de ligne du source qui ont abouti d la levee de I'exception. La classe 
Exception est munie d'un message s, qui decrit precisement I'exception levee. 
Les exceptions correspondent d des problemes d'entree/sortie derivent de la classe lOExcep- 
tion. Parmi ces erreurs, la classe InterruptedlOException porte un attribut qui indique I'etat du 
transfert de donnees au moment de la levee de I'exception. Un gestionnaire d'exception qui 
accepte en entree la classe generale Exception est aussi capable de gerer des lOException, 
des EOFException, etc. 
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Region interruptible et interruption 

Le mecanisme de gestion d'exceptions permet de les representer telles qu'on les trouve dans 
les langages de programmation objet. UML propose un deuxieme mecanisme analogue, 
mais moins precis, de gestion des interruptions : les regions interruptibles. II est mieux 
adapte aux phases de modelisation conceptuelle ou de modelisation metier, qui demandent 
une moins grande precision. Le but est de representer graphiquement un enchainement 
nominal et une alternative qui interrompt le cours du traitement. 

Une region interruptible est representee par un cadre arrondi en pointilles. Si l'evenement 
d'interruption se produit, toutes les activites en cours dans la region interruptible sont stop- 
pees et le flot de controle suit la fleche en zigzag qui quitte la region. Aucune contrainte sur 
la suite du traitement n'est imposee : a priori, l'activite ainsi interrompue n'est pas reprise. 
Cette semantique est differente de celle des gestionnaires d'exception et correspond mieux 
aux interruptions dans les activites metier. 



EXEMPLE Dans cet exemple, l'activite debute d la reception d'une commande d'un client. Toute la suite 

de l'activite gerer commande est interruptible : le client est libre d'annuler sa commande d 
tout moment. S'il passe I'ordre d'annuler, le dossier est efface. Une fois que le paiement 
est effectif et que la commande est prete, il devient impossible de I'annuler : la transaction est 
dument enregistree et le dossier cloture. 

Apres reception d'un ordre d'annulation, et durant l'activite annuler dossier, l'activite traiter 
paiement peut continuer d s'executer. Cependant, elle est, elle aussi, interrompue quand le 
flot de traitement a fini d'annuler le dossier et que I'etat final est atteint (cela termine tous les 
flots de l'activite). 
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Region interruptible. 
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4.3 Sequence et iteration 



Une zone d 'expansion, graphiquement representee par un cadre en pointilles, exprime une 
action repetee sur chaque element d'une collection. Une collection peut etre implementee 
par un tableau ou une liste par exemple. Le type des objets contenus dans la collection doit 
etre connu. La collection est passee a la zone d'expansion a travers un pin d 'expansion, gra- 
phiquement represents par un rectangle divise en compartiments, cense evoquer la notion 
de liste d'elements. 

L'activite a Finterieur de la region d'expansion est executee une fois pour chaque item de la 
collection, a la maniere d'un foreach des langages Python, Perl ou Fortran. Cette activite 
interne doit prendre en entree un objet respectant le type de la collection : vu de l'exterieur 
de la region, le pin d'expansion est de type Collection<Objet>, mais vu de Finterieur, il est de 
type Objet. A chaque execution de l'activite interne, sa valeur de retour est inseree dans la 
collection de sortie a la meme position (indice) que son entree. L'activite interne peut egale- 
ment se terminer sans rendre de valeur, ce qui correspond a un mode nitre : la collection 
resultante compte alors moins de valeurs que Fentree. 

Une zone d'expansion peut etre de Fun des trois types suivants, signale par un mot-cle place 
dans l'angle de la region d'expansion : 

• parallel. Les executions de l'activite interne sur les elements de la collection sont inde- 
pendantes et peuvent etre realisees dans n'importe quel ordre ou meme simultanement. 
Une implementation sur une architecture parallele peut done efficacement realiser ce 
traitement. 

• iterative. Les occurrences d' execution de l'activite interne doivent s'enchainer sequentiel- 
lement, en suivant Fordre de la collection d'entree. Si cette derniere n'a pas d'ordre de 
parcours bien defini (table de hachage par exemple), un ordre quelconque est choisi 
de facon indeterministe. 

• stream. Les elements de la collection sont passes sous la forme d'un flux de donnees a 
l'activite interne, qui doit etre adaptee aux traitements de flux. Cela permet de controler 
plus finement le parallelisme des executions. 



EXEMPLE Passer un texte en majuscules 

Cette activite permet de passer un texte en majuscules. Quel que soit I'ordre des traitements, 
le resultat est correct. El le porte done le mot-cle parallel. 
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Zone d'expansion. 



string : char[] 



«parallel» 



: char \f 
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if (c >= 'a' && c <= 'z') 
return c-'a'+'A'; 

else 

return c; 
' □ ' 



:char 



: char[] 



UML 2 a introduit le mecanisme des zones d'expansion pour permettre une meilleure 
expression du parallelisme des actions. 



Conclusion 

La vue offerte par les diagrammes d'activites est centree sur les traitements. Elle permet de 
modeliser efficacement le cheminement de flots de controle et de flots de donnees. Les 
apports importants d'UML 2 au niveau de ces diagrammes assurent Fexpression precise du 
comportement : la generation de code est un objectif central dans ces diagrammes. 

En fournissant une vision abstraite des traitements, la modelisation des activites ne fixe 
cependant pas completement les choix d'implementation. L'expression de mecanismes 
concurrents, par exemple, n'impose pas leur realisation sur une architecture parallele. De 
meme, la manipulation de variables multivaluees et de collections permet un bon niveau 
d'abstraction. 

Les diagrammes d'activites sont particulierement utiles dans la phase de conception pour la 
description detaillee des cas d'utilisation. On utilise alors une syntaxe libre, qui decrit des 
actions conceptuelles de haut niveau. lis sont egalement utiles dans la phase de realisation 
pour la description precise des traitements, avec un niveau de details qui se rapproche d'une 
specification pleinement executable. On utilise alors une syntaxe inspiree d'un langage de 
programmation pour decrire les actions et Ton peut preciser finement la gestion des excep- 
tions ou le passage des parametres. 

La description graphique des traitements permet de mieux cerner le cheminement des alter- 
natives. Les mecanismes d' imbrication et d'appels (call) permettent de preserver une certaine 
concision. Cependant, evitez les diagrammes d'activites quand le traitement est tres lineaire : 
une description textuelle de l'enchainement est alors suffisante dans la plupart des cas. 

Arrive a ce stade du livre, sept diagrammes ont ete presentes : le diagramme des cas d'utili- 
sation, celui des classes et des objets, le diagramme de sequence et de communication, le 
diagramme d'etats- transitions et, enfin, le diagramme d'activites. lis permettent de modeli- 
ser quasiment tout systeme. Deux autres diagrammes ont volontairement ete relegues dans 
les annexes : le diagramme de composants et celui de deploiement. lis sont, en effet, suffi- 
samment simples pour ne pas faire l'objet d'un chapitre entier. Le chapitre suivant, quant a 
lui, presente comment tous ces diagrammes s'assemblent et se completent pour donner une 
vision globale et coherente d'un systeme. La partie pratique de ce chapitre est constitute 
d'une etude de cas. 
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Problemes 
et exercices 

Les exercices suivants couvrent les principaux concepts des diagrammes d'activites. 



Exercice 1 Programmation en activites 



Enonce 



1. Les chaines de caracteres du langage C sont codees comme un tableau de caracteres non 
nuls, termine par un caractere '\0'. Par exemple, la chaine s=" hello!" est codee 
comme suit : 

s[0] s[1] s[2] s[3] s[4] s[5] s[6] 

'h' 'e' '1' '1' 'o' 1 ! ' '\0' 

Decrivez une activite implementant la fonction strlen, qui prend en entree un tableau 
de caracteres et rend un entier correspondant a la taille de la chaine. Exemple : 
strlen( "hello! " )=6. 

2. Proposez le diagramme d'activites qui compte les mots, les lignes et les caracteres de 
son entree. 

La fonction getchar() lit le prochain caractere disponible sur F entree. S'il s'agit du 
caractere special EOF, le programme affiche ses resultats et se termine. 

Loperation bool isWhitespace(c : char) repond vrai si le caractere passe en argument 
est considere comme un espace. 



Solution 



1. Le traitement est relativement simple : on itere sur le tableau de caracteres de l'entree ; 
quand la valeur du caractere est '\0', on rend l'index courant. Une implementation effi- 
cace en C manipulerait plutot deux pointeurs sur caractere que l'indice len, mais cela 
suppose l'existence d'operations arithmetiques sur les pointeurs, absentes en UML. 



Figure 5.20 

Calcul de la longueur 
d'une chaine de 
caracteres. 



char[] s 



int len^^^ 




2. Une solution est proposee a la figure 5.5. 
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Exercice 2 Vente en ligne 



Un site de vente en ligne propose des produits, places dans un panier virtuel tandis que 
l'utilisateur navigue. Pour valider ses achats, il clique sur le bouton Sortir du magasin. On lui 
propose alors de se connecter a un compte existant, ou d'en creer un s'il n'en a pas encore. 

Pour creer un nouveau compte, l'utilisateur doit fournir une adresse de messagerie, qui 
sert egalement de login, son nom et son adresse, eventuellement une adresse de livraison, 
et ses coordonnees bancaires. On prevoit le cas oil l'adresse de messagerie est deja associee 
a un compte. Si la validation de ces informations reussit, on cree un nouveau compte et 
Ton propose a l'utilisateur de s'y connecter. 

On passe ensuite a la confirmation des achats. 

Modelisez cette procedure a l'aide d'un diagramme d'activites. 



Solution 



L'enonce est suffisamment vague pour donner lieu a de nombreuses interpretations. Cela 
est typique d'une specification textuelle des besoins, telle qu'on en trouve dans un cahier des 
charges. La solution proposee ici fixe done un certain nombre de choix d'organisation de la 
procedure. 

On se concentre sur la partie concernant l'authentification de l'utilisateur, et la creation 
d'un compte le cas echeant. 



Fiqure 5.21 
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^organisation proposee correspond a une interface de type « wizard » : il faut valider tous 
les champs d'une page, cliquer sur Suivant, pour passer a la validation des prochains champs. 
Si les informations sont incorrectes, un message avertit l'utilisateur et l'ecran suivant s'affiche. 
Cette verification des champs n'est done pas representee ici : il revient a l'activite de saisie de 
se terminer quand la saisie est validee. 

Chaque activite correspond done assez bien a un ecran d'interface, les transitions exprimant 
une navigation possible entre ces ecrans. Vous pourrez reutiliser ces activites ailleurs. Par 
exemple, la modification de Fadresse de livraison est accessible depuis un menu quand l'uti- 
lisateur est connecte a son compte. 

Ce niveau de description est bien adapte a la description d'interfaces homme-machine et 
permet de se concentrer sur la vision logique d'un traitement, sans se perdre dans le modele 
structurel en classes. 



Exercice 3 Algorithmique 



Enonce 



Les diagrammes d'activites permettent de raisonner sur des algorithmes, au cours de l'acti- 
vite de specification detaillee. 



Vous allez utiliser les diagrammes d'activites pour decrire des algorithmes de tri. 

1. Elaborez une activite swap qui prend trois arguments, un tableau tab et deux indices a 
et b, et echange le contenu de la case tab [a] et tab[b]. 

2. En utilisant swap, decrivez un tri par bulles d'un tableau tab de taille n. L'algorithme 
consiste en n - 1 parcours du tableau, chacun amenant (par des appels successifs a swap 
sur des cases contigues) le plus grand element du tableau en derniere position (done en 
position n — 1 — i a l'iteration numero i). 

3 .L'algorithme glouton du tri par bulles est peu efficace, en raison du grand nombre de 
copies inutiles realisees. Ecrivez un tri par insertion, qui opere en n iterations : a chaque 
iteration de numero i, considerez la plage de valeurs de 0 a i - 1 comme triee. L'algo- 
rithme consiste a chercher le bon endroit ou inserer la valeur en position i, afin de trier 
la plage de valeurs de 0 a i. Copiez la valeur en position i dans une variable temporaire 
et decalez les valeurs avant cette position vers la droite (une par une) jusqu'a trouver 
l'endroit ou recopier la valeur de la variable temporaire. 

4. L'algorithme precedent a encore une complexite elevee. Les tris les plus efficaces sont 
fondes sur des appels recursifs qui font chuter la complexite. La fusion de deux tableaux 
tries en un tableau trie est une operation de complexite lineaire sur la taille du tableau 
resultant. Pouvez-vous concevoir un algorithme (tri par fusion) qui s'appuie sur cette 
propriete et des appels recursifs pour trier plus efficacement un tableau ? Indication : 
vous pouvez definir une activite tri fusion qui prend un tableau t et deux indices, g et d, 
et trie la portion du tableau comprise entre les indices g et d. 



Solution 



Notons que les algorithmes presentes ici sont fondes sur le tres classique livre Le Langage C, 
de Kernighan et Ritchie. La lecture comparee des versions en C et en diagrammes d'activites 
est instructive. 

1. Utilisez une variable temporaire pour stocker l'une des deux valeurs des variables a 
echanger avant de l'ecraser en la remplacant par la valeur de l'autre variable. Ce dia- 
gramme met bien en avant le flot des valeurs. La variable temporaire est representee par 
un pin. 
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Comme vous n'avez pas plus de precisions sur le type des objets contenus dans le tableau, 
utilisez un template pour representer ce type : l'operation est en effet generique et valable 
quel que soit le type T contenu dans le tableau. 



Figure 5.22 
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2. Le diagramme de la figure 5.23 presente une structure interessante pour la representation 
de boucles, qui fait apparaitre clairement les deux boucles imbriquees. Les cycles dans 
le graphe traduisent le phenomene de bouclage , et l'imbrication est visible grace a la 
hierarchic 

Le placement des objets constituant les boucles (corps de boucle, condition d' arret...) 
est reconnaissable visuellement ; il est reutilise plusieurs fois dans les diagrammes qui 
suivent. 

Deux points de decision font apparaitre plus clairement a la fois le debut et la fin de 
Falternative dans la boucle interne. 

Une nouvelle contrainte sur le type contenu dans le tableau impose que ce type soit muni 
d'une relation d'ordre total pour que puisse s'operer la comparaison de ses elements. 
Indiquez-la en mentionnant que le type Tdoit realiser Finterface Comparable. (Voir aussi 
la section 3.3 et l'exercice 4 du chapitre 3.) 



Figure 5.23 
Tri par « bulles ». 
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3. Cette version du tri limite le nombre de copies intermediaries de valeur. Elle realise un 
« roulement » des variables (au lieu de les echanger deux a deux) qui deplace tout un bloc 
avant de recopier la variable temporaire. 

La structure de l'algorithme reste assez proche du tri par bulles. De ce fait, il a la meme 
complexite theorique en 0(n 2 ) en nombre d'operations que le tri par bulles, mais realise 
un peu moins de copies que lui. Vous vous en apercevrez en comparant les deux 
schemas : l'imbrication des deux boucles apporte le facteur n 2 et les differences entre 
les actions dans chaque boucle n'apportent qu'un facteur constant, done theoriquement 
negligeable en complexite. 



Figure 5.24 
Tri par selection. 
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Tri par insertion 
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4. Le tri par fusion permet de montrer la modelisation de concepts algorithmiques avances, 
en particulier la recursivite et le parallelisme. Ce type de tri est relativement puissant : il a 
une complexite comparable au quicksort, devenu standard, et se prete egalement a une 
implementation sur des listes chainees. C'est recemment devenu l'algorithme de tri 
standard (au lieu de quicksort) du langage Perl par exemple. 

Comme le montre le diagramme presente a la figure 5.25, il est possible de l'implementer 
avec des traitements en parallele, ce qui se prete aux architectures paralleles. Pour autant, 
il n'est pas obligatoire de l'implementer avec du parallelisme : toute execution qui respecte 
l'enchainement des actions et les barres de synchronisation est correcte. 

Les numeros indiques a cote des pins donnent l'ordre des arguments. L'appel recursif est 
represente comme un appel de fonction normal. 

L'algorithme correspond a l'approche « diviser pour regner ». A chaque profondeur dans 
l'appel recursif, vous triez un tableau deux fois plus petit : la moitie du tableau precedent. 
La complexite theorique totale des traitements n'est qu'en 0(n log n), au lieu de 0(n 2 ), 
comme les deux algorithmes precedents. 
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Figure 5.25 
Tri par fusion. 
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EXERCICE 4 VlDEOCLUB 



Enonce 



En vous basant sur la description textuelle du videoclub de l'exercice 5 du chapitre 1, 
representez par un diagramme d'activites le cas d'utilisation « Emprunter une video ». 



Solution 



La description des cas d'utilisation est Fune des applications immediates des diagrammes 
d'activites. Elle permet d'accompagner la description textuelle par un schema synthetique, 
mais ne la remplace pas. 
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Figure 5.26 

Le cas d'utilisation 
« Emprunter video ». 
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On retrouve sur ce diagramme a la fois la sequence nominale et les differents enchainements 
alternatifs et d'exceptions. On distingue les actions se rapportant au client, qui ne fait pas 
directement partie du systeme. 

A valeur d'exemple, deux mecanismes differents sont utilises pour representer le delai de 15 
secondes pendant lequel le client recupere sa cassette ou sa carte. 

Dans le premier cas, une exception gere cet evenement : cela permet, en cas de levee de 
Fexception, de reprendre le traitement au meme point que si le client avait recupere sa cas- 
sette et d'enchainer sur ejecter carte. 

Dans le deuxieme cas, deux actions sont mises en concurrence : prendre carte et le time event 
de 15 secondes. L'astuce ici est que le premier flot de controle qui atteint le nceud final force 
la terminaison de tous les autres flots. Si ce comportement n'est pas celui souhaite, il faut 
utiliser un nceud flow final (cercle avec une croix) pour terminer un flot sans affecter les 
autres flots de la region. 



Exercice 5 Cache d'operations 



Cet exercice aborde la modelisation d'un mecanisme de cache, permettant de limiter le cout 
des calculs repetes. Cette strategic est tres utile pour les calculs couteux en temps, mais 
consomme en contrepartie plus de memoire. 
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Figure 5.27 

Les classes 
proposees pour 
implementer 
un cache. 



Cet exercice propose de modeliser un mecanisme de cache. Une classe Map represente une 
table associative. Elle contient conceptuellement des couples <cle,valeur>. La recherche de 
la valeur associee a une cle donnee (operation get) est tres rapide (complexity theorique- 
ment constante, quel que soit le nombre de couples dans la table). Une seule valeur peut 
etre associee a chaque cle distincte : si une valeur est deja associee a la cle, l'operation put 
d'ajout a la table ecrase l'ancienne valeur. Les tables de hash ou les arhres de recherche sont 
des implementations frequemment rencontrees de tables associatives. 



Map 



Object get (Object key)o 

Object put (Object key, Object value JO 



«postcondition» N 

si la cle key n'est pas dans la table rends la reference nulle. 
sinon rends la valeur associee a la cle key 



«postcondition» 
la valeur value a ete associee a la cle key dans la table 



{abstract} 
Cache 



-map : Map 



+Object compute (arg: Object) 

#Object doComputation (Object) {abstract} 



Fonction2 



#Object doComputation (Object) 



Fonctionl 



#Object doComputation (Object) 



Realisent un 
calcul couteux 



Vous allez realiser une classe abstraite Cache qui offre a ses classes derivees une fonction- 
nalite de cache. Elle est munie, pour cela, d'une instance de la classe Map, qui sert a stocker 
les resultats deja calcules par cette instance de fonction. 

Les classes derivees de Cache realisent un calcul couteux en temps. De telles classes, qui 
servent a realiser un calcul, sont parfois appelees « foncteurs ». Elles doivent implementer 
l'operation de visibility protegee doComputation (couteuse). Elles offrent publiquement 
l'operation compute aux utilisateurs de la fonction. 

1. Decrivez a l'aide d'un diagramme d'activites le comportement de l'operation compute. 

2. Prevoyez que l'argument passe a compute n'est pas du bon sous-type de Object pour la 
fonction concrete. Si c'est le cas, l'operation doComputation risque de lever une exception 
de typage quand elle essaie d'interpreter l'objet passe en argument (ClassCastException 
par exemple en Java standard). Pour offrir une gestion propre, si une erreur de ce type se 
produit, vous voulez que compute leve une exception (non standard) de type TypeExcep- 
tion. Enrichissez le diagramme precedent pour representor ce mecanisme. 



1. L'operation compute cherche si le resultat de l'operation a deja ete calcule pour son argu- 
ment. Si c'est le cas, elle rend la valeur stockee dans le cache. Sinon, elle realise le calcul 
par un appel a la fonction abstraite doComputation. Ensuite, elle ajoute ce nouveau resul- 
tat dans la table avant de le rendre a l'appelant. 
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Figure 5.28 

Comportement 
associe a I'operation 
compute du cache. 
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2. Supposez que doComputation peut lever une exception : il faut proteger l'activite qui 
appelle cette fonction par un gestionnaire d'exception. Enrichissez done le diagramme en 
ajoutant ce gestionnaire et un pin pour representer la nouvelle signature complete (avec 
l'exception TypeException) de compute. Le corps du gestionnaire d'exception se contente 
de lever l'exception appropriee : I'operation d'ajout dans la table qui suit l'activite 
doComputation n'est pas realisee. 
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1 . Un processus pour la 
modelisation d'un systeme 1 88 

2. Guide methodologique 1 89 

Etude de cas 196 




Les principaux diagrammes realises avec UML ont ete 
presentes dans les chapitres precedents. Or, les modeles 
elabores avec ces differents diagrammes s'assemblent et se 
completent pour donner une vision globale et coherente d'un 
systeme. D'autre part, la modelisation d'un systeme n'est 
pas un processus lineaire (ou les modeles sont elabores 
selon un enchamement immuable), mais au contraire un 
processus iteratif, voire incremental. Ainsi, I'ordre de 
presentation des diagrammes dans les chapitres precedents, 
sans etre denue d'interet, est quelque peu arbitraire, 
et ne definit pas un processus immuable applicable d 
la modelisation de n'importe quel systeme. Ce chapitre 
presente un processus qui est suffisamment general pour 
convenir, moyennant quelques adaptations, d la plupart 
des problemes. Dans la partie exercices, ce processus est 
illustre par une etude de cas. 
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□ Un processus pour la modelisation d'un 
systeme 

A l'image des langages de programmation qui permettent de developper des applications 
pour tous les domaines, UML est un langage capable de decrire n'importe quel systeme. Ses 
elements de base (les rectangles qui representent des classes, les traits qui materialisent des 
associations entre classes, etc.) s'assemblent pour former des diagrammes. Un diagramme 
est un modele. Elaborer tous les modeles donne l'assurance d'avoir une vision complete d'un 
systeme, mais parfois, une vision partielle suffit. Le modelisateur est done libre de choisir les 
modeles qui conviennent a une application particuliere. C'est cette liberte de choix qui fait 
la force d'UML. A contrario, cet aspect boite a outils en fait un langage difficile a appliquer : 
le modelisateur debutant se trouve souvent perdu face a tant de possibilites. 

La richesse d'UML se retrouve dans la profusion de diagrammes qu'il permet de construire : 

• diagramme de cas d' utilisation ; 

• diagramme de classes et d'objets ; 

• diagramme d'interaction (diagrammes de sequence, de communication, de timing) ; 

• diagramme d'etats-transitions ; 

• diagramme d'activite ; 

• diagramme de composants ; 

• diagramme de deploiement. 

Les deux derniers diagrammes de la liste, que nous n'avons pas encore abordes, sont decrits 
a la fin de l'ouvrage. 

Ce nombre important de diagrammes pose la question de l'ordre dans lequel il faut les 
elaborer. Y a-t-il une marche a suivre ? Un processus immuable ? Evidemment, et malheu- 
reusement non ! La diversite des systemes a modeliser rend illusoire la definition d'un tel 
processus. Toutefois, a defaut d'etre immuable, la marche a suivre doit respecter les etapes 
du cycle de developpement d'un systeme : 

• planification du projet ; 

• phase d'analyse ; 

• conception ; 

• implementation ; 

• tests ; 

• deploiement ; 

• maintenance. 

La planification du projet comprend notamment la definition du probleme, l'etablissement 
d'un calendrier ainsi que la verification de la faisabilite du projet. L' analyse permet de preci- 
ser l'etendue des besoins auxquels doit repondre le systeme, puis de specifier et de compren- 
dre ce que doit faire ce systeme (sans se preoccuper de la realisation). La conception definit 
comment le systeme va etre realise (c'est l'etape oil des choix techniques sont faits). L'imple- 
mentation, quant a elle, correspond a la realisation du systeme (dans le cas d'un logiciel, il 
s'agit de la phase d'implementation dans un langage de programmation). Les tests permet- 
tent, avant la mise en production, de verifier l'adequation entre la solution et les besoins 
initiaux. Enfin, la maintenance permet de conserver en etat de marche un systeme en 
production. 
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UML couvre la plupart des etapes du cycle de vie d'un projet (figure 6.1). 



Figure 6.1 

La place d'UML 
dans le cycle de 
developpement 
d'un systeme. 
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Historiquement, c'est d'abord durant la phase d'analyse qu'UML a ete utile. La version 2 
d'UML a considerablement etendu le langage, notamment avec l'apparition des classeurs 
structures qui sont utiles en phase de conception. Cependant, il est encore trop tot pour 
affirmer qu'UML va s'imposer comme un standard dans ce domaine. D'autre part, l'OMG, 
l'organisme qui supporte UML, a l'ambition d'eviter la rupture trop brutale qui a toujours 
existe entre les phases de modelisation et la phase d'implementation (la ou UML est aban- 
donne au profit d'un langage de programmation). Son objectif est qu'UML puisse, a terme, 
etre utilise tout au long du cycle de vie d'un projet, y compris pour donner une implemen- 
tation a un systeme, ce qui n'est pas le cas aujourd'hui. En revanche, le langage permet 
depuis longtemps de representer un systeme tel qu'il sera deploye grace aux diagrammes de 
deploiement (voir l'annexe D). De plus, les scenarios qui presentent des realisations des cas 
d'utilisation (sous forme textuelle, avec des diagrammes de sequence ou d'activite) peuvent 
servir de base pour definir les tests du systeme implements. 

La recherche d'un processus unifie qui s'adapte a tous les projets a donne lieu a de nom- 
breux travaux. Parmi ceux-ci, deux se distinguent : le RUP (Rational Unified Process) et le 
MDA (Model Driven Architecture). L'ampleur de ces travaux depasse le cadre de ce livre, 
aussi, nous nous contenterons dans ce chapitre de decrire une methode relativement simple, 
mais largement utilisee dans le domaine du developpement de logiciels [Blaha 2005]. Elle 
est illustree par une etude de cas dans la partie exercices de ce chapitre. 



0 Guide methodologique 

Considerons un projet de developpement d'un systeme logiciel. La premiere etape du cycle 
de vie, la planification, a permis de definir le probleme, d'etablir un calendrier, et de verifier 
la faisabilite du projet. Notre description commence a l'etape d'analyse. Rappelons quelle 
sert a preciser le besoin auquel doit repondre un systeme, et a specifier et comprendre ce 
que ce systeme doit faire. 

Remarque 

La description qui suit est succincte mais assez complete car nous decrivons toutes les etapes 
d'un processus (meme celles ou UML n'est d'aucune utilite), afin que vous puissiez vous ren- 
dre compte de la portee, mais egalement des limites d'UML. Nous insistons particulierement 
sur les phases d'analyse et de conception car c'est Id ou UML est le plus utile. La phase de 
deploiement est abordee dans l'annexe D et dans I'etude de cas. Des indications sur la 
facon d'implementer un diagramme de classes dans un langage de programmation objet 
sont egalement donnees dans l'annexe E. 
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Remarque (suite) 

Nous avons separe la description du processus de I'etude de cas, afin de ne pas encombrer 
la partie theorique (et done generale) avec des details lies d une application. Cependant, 
nous conseillons, lors de la premiere lecture, de ne pas parcourir d'une seule traite la partie 
cours avant de passer d I'etude de cas. II vaut mieux alterner partie theorique et mise en 
pratique. Plus tard, le lecteur pourra revenir sur la partie theorique seule, qu'il verra alors 
comme le resume d'une methode. 
I 

2.1 Phase d'analyse 



Le concept de reutilisabilite, qui consiste a reprendre une partie d'un logiciel pour Futiliser 
dans une autre application, et le concept d'evolutivite, qui permet d'ajouter des nouvelles 
fonctionnalites a un logiciel existant, ont ete des raisons fondamentales au developpement 
de l'approche objet du genie logiciel. Pour etre effectifs dans une application, ces mecanis- 
mes doivent etre mis en place des la phase d'analyse. II faut separer I'etude du domaine de 
l'application de l'application elle-meme. Le domaine, e'est par exemple celui d'une banque, 
et l'application, un logiciel de gestion de comptes bancaires : d'une application bancaire a 
une autre, le domaine ne va pas changer car e'est toujours d'une banque qu'il s'agit. 

La phase d'analyse d'un logiciel se compose de deux parties : 

• Fanalyse du domaine de l'application ; 

• Fanalyse de l'application. 

Analyse du domaine de l'application 

C'est durant la phase d'analyse du domaine qu'une premiere version du diagramme de classes 
est elaboree. Ce modele doit capturer les classes qui modelisent des entites presentes dans le 
domaine de l'application. Cette premiere version du diagramme de classes est batie avec des 
experts du domaine (des banquiers pour un systeme bancaire par exemple). Ce modele est 
elabore plutot au debut de la phase d'analyse, et, en tout cas, independamment de la phase 
d'analyse de l'application : le modele du domaine sera ainsi plus stable, et il pourra facile- 
ment evoluer car il sera independant des details de l'application (le modele du domaine ne 
s'interesse pas aux fonctionnalites de l'application). Apres avoir elabore le modele des classes 
du domaine, Fanalyse se poursuivra par la construction de diagrammes d'etats-transitions 
pour les classes ayant des etats complexes. 

Modele des classes du domaine. Le chapitre 2 donne des indications pour construire un 
diagramme de classes. La demarche pour batir le diagramme de classes du domaine est la 
meme. Aussi nous contenterons-nous de donner un resume des etapes a suivre : 

• trouver les classes du domaine ; 

• preparer un dictionnaire des donnees ; 

• trouver les associations entre les classes ; 

• trouver les attributs des classes ; 

• organiser et simplifier le diagramme en utilisant l'heritage ; 

• tester les chemins d'acces aux classes ; 

• iterer et affmer le modele ; 

• regrouper des classes dans des paquetages. 
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Remarque 




Un modele est rarement correct des sa premiere construction. II est souvent necessaire de 
revenir plusieurs fois dessus afin de I'affiner. Par exemple, il ne faut pas s'attendre a trouver 
toutes les associations des la premiere construction du diagramme de classes. La modelisation 
ne se fait pas par une succession lineaire d'etapes, mais progresse souvent par iterations. 



Modele des etats du domaine. Un diagramme de classes n'est qu'un modele et, dans un logi- 
ciel en cours de fonctionnement, il n'y a pas de classe mais des objets, instances de classes. Un 
diagramme de classes n'est qu'une abstraction de la realite. Le modelisateur a besoin de des- 
cendre a un niveau plus bas (c'est-a-dire au niveau des objets). Durant l'analyse, il ne faut 
cependant pas descendre jusqu'au niveau physique : il est tout a fait premature de s'interesser 
a Fallocation des ressources memoire pour les objets, et du temps processeur pour les metho- 
des. En revanche, il est necessaire de connaitre le cycle de vie des objets (a quelle etape de la 
vie du logiciel en production les classes vont donner naissance a des objets, comment ceux-ci 
vont etre utilises et a quelle etape ils seront detruits). La description de ce cycle revient aux 
diagrammes d'etats-transitions. Cependant, seules les classes dont les instances ont un cycle 
de vie complexe doivent donner lieu a des diagrammes d'etats-transitions. 

La demarche pour construire le modele des etats du domaine est la suivante : 

• identifier des classes du domaine ayant des etats complexes ; 

• definir les etats ; 

• trouver les evenements qui vont engendrer des transitions entre etats ; 

• construire les diagrammes d'etats. 



Remarque 

II est important de suivre les differentes etapes de la demarche dans I'ordre indique ci-dessus. 
Notamment, il faut trouver les etats avant les evenements. De nombreux evenements sont 
produits par les utilisateurs d'un systeme. Ils sont pris en compte au moment ou sont decrits 
les cas d'utilisation, et done lies d une application particuliere. Or, le modele du domaine 
doit etre independant des applications. 
I I 

Analyse de ^application 

L'implementation du modele des classes du domaine donne lieu a un systeme statique. Ce 
modele n'indique pas comment des instances de classes interagissent pour realiser les fonc- 
tionnalites d'une application. Un diagramme de classes, meme implements, n'offre aucune 
fonctionnalite aux utilisateurs. Pas plus qu'une implementation du modele des etats du 
domaine qui se contente de definir le cycle de vie des objets separement les uns des autres. 
Apres avoir construit le modele du domaine, il faut s'interesser aux applications qui utili- 
sent ses classes. 

Modele des interactions de 1'application. C'est durant la phase d'analyse de l'application 
qu'un modele des interactions du systeme est produit. L'analyse debute par la construction 
du diagramme de cas d'utilisation et se poursuit par la description des scenarios d'utilisa- 
tion des cas. La demarche est decrite en detail dans le chapitre 1. Nous nous contentons ici 
d'en donner un resume : 

• determiner les limites du systeme ; 

• trouver les acteurs ; 
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• trouver les cas d' utilisation ; 

• construire le diagramme de cas d'utilisation ; 

• preparer les scenarios pour decrire les cas ; 

• ajouter des sequences alternatives et des sequences d'exceptions aux scenarios ; 

• preparer des diagrammes d'activite pour des cas d'utilisation complexes ; 

• realiser une verification croisee des modeles du domaine et de Fapplication. 

La verification se fait a partir des scenarios. Elle permet de controler si les classes ont tous les 
attributs et tous les chemins (les associations) necessaires pour y acceder. 



Modele des classes de l'application. Les classes du diagramme de classes ne suffisent pas a 
realiser une application. Des instances de ces classes doivent interagir avec les acteurs du 
logiciel (les utilisateurs, les peripheriques, etc.). II n'est pas souhaitable que les acteurs inter- 
agissent directement avec les instances des classes du domaine. La logique interne de l'appli- 
cation doit etre independante des acteurs. L'interface utilisateur du logiciel, par exemple, doit 
pouvoir evoluer tandis que le cceur de l'application doit rester identique. C'est le principe 
fondamental du decoupage en couches d'une application (figure 6.2) : a l'une des extremi- 
tes de l'application se trouve l'interface utilisateur et, de l'autre cote, le logiciel interagit avec 
des supports de stockage (bases de donnees, annuaires, fichiers, etc.) via une couche de ser- 
vices. L'implementation du diagramme des classes trouvera sa place dans la couche metier. 



Figure 6.2 

Le decoupage 
en tiers d'une 
application. 



Utilisateurs 











/ 


Interface utilisateurs 


/ 


Logique applicative 


/ 


Logique metier 


/ 


Services : acces aux donnees, 
transactions... 


/ 



Supports de stockage 



Remarque 




La tendance actuelle du developpement de logiciels, pronee notamment par I'approche 
dite composant de la programmation, va vers la multiplication du nombre de couches. On 
parle alors d'un decoupage en N-tiers ! 



Le modele des classes de l'application concerne toutes les classes supplementaires qu'il 
convient d'ajouter pour interfacer la logique applicative avec les acteurs du logiciel. La 
demarche est la suivante : 

• specifier l'interface homme-machine ; 

• definir les classes a la peripheric du systeme. 
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En modelisation objet, l'interface est un objet, ou un groupe d'objets, qui permet d'interagir 
avec l'application. Durant la phase d' analyse, vous devez vous interesser non pas a la presen- 
tation de l'interface utilisateur mais uniquement aux flots de donnees et de controle trans- 
mis via l'interface. II ne faut pas non plus trop detainer les entrees-sorties, mais considerer 
globalement les requetes qui permettent d'acceder a un service, la reservation d'une place 
de cinema, par exemple. Cela ne doit cependant pas vous empecher de construire les 
maquettes des interfaces pour vous aider a etablir leurs specifications. 

Les classes a la peripheric du systeme ont pour role de convertir les informations utiles au 
logiciel, du format comprehensible par le monde exterieur au format interne du logiciel, et 
vice versa. 

En plus des objets definissant les interfaces de l'application, un logiciel contient un ou plu- 
sieurs objets actifs qui le controlent. Ces objets sont appeles « controleurs ». lis recoivent des 
signaux du monde exterieur, ou des objets a l'interieur du systeme, et reagissent en invo- 
quant des operations sur d'autres objets. Chaque controleur a pour tache de traiter un com- 
portement particulier du logiciel. 



Remarque 

UML n'est pas d'un grand secours lors de cette phase de I'analyse, meme si les classes qui 
y sont decouvertes peuvent etre representees avec le formalisme du diagramme de classes. 
La couche d'acces aux donnees est construite lors de la phase de conception et non pas 
pendant la phase d'analyse. II faut d'abord avoir decompose successivement les classes et 
les methodes pour arriver aux supports de stockage. 



La derniere etape pour l'elaboration du modele des classes de l'application consiste a 
controler la coherence de ce modele avec celui des interactions. II s'agit de reprendre les cas 
d'utilisation arm de verifier comment les modeles interagissent : par exemple, une donnee 
saisie via l'interface homme-machine est confiee a un objet controleur qui la transmet a un 
objet du domaine via l'invocation d'une operation, etc. Lors de cette etape, le langage OCL 
peut etre utilise pour « naviguer » parmi les classes. 

Modele des etats de l'application. Tout comme les classes du domaine, les classes de l'appli- 
cation peuvent avoir des etats complexes. Chacune d'elles necessite done un diagramme 
d'etats-transitions. Pour construire un tel diagramme, la demarche est la suivante : 

• identifier des classes de l'application ayant des etats complexes ; 

• trouver les evenements ; 

• construire les diagrammes d'etats ; 

• verifier la coherence avec les modeles precedents. 

Remarque 

Les diagrammes des etats-transitions de l'application se construisent a peu pres de la meme 
maniere que ceux du domaine de l'application. Seul I'ordre des etapes differe : pour l'appli- 
cation, il faut d'abord trouver les evenements avant les etats, alors que e'est le contraire 
pour le domaine. En effet, les etats de l'application sont elabores apres que les cas d'utili- 
sation, qui sont declenches par des evenements provenant des acteurs, ont ete definis. On 
dispose done des evenements avant de construire les etats. II n'en est pas de meme pour 
I'etude du domaine qui, parce qu'elle doit etre independante des applications, ne peut pas 
reposer sur des evenements. 
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Ajout des operations. A ce stade de l'analyse, les classes du domaine de l'application peuvent 
contenir quelques operations (celles qui ont ete suggerees par l'etude du domaine). Ces 
operations sont interessantes car elles sont propres au domaine, et done independantes des 
applications. Cependant, les operations liees a l'application ne sont pas forcement toutes 
decouvertes. Elles peuvent etre deduites de l'etude des cas d' utilisation et de leurs descrip- 
tions par les diagrammes de sequence et/ou d'activite produits. 

2.2 Phase de conception 



Avertissement 



La phase de conception requiert beaucoup a" experience. Cela depasse largement le cadre 
de cet ouvrage. La description qui en est faite ici est tres sommaire, mais neanmoins utile 
pour se rendre compte de I'interet d'utiliser UML lors de cette phase. 



Les concepteurs ont pour tache principale de preparer l'implementation. Pour un logiciel, 
l'implementation consiste a traduire le plus mecaniquement possible des modeles d'analyse 
et de conception dans un ou plusieurs langages de programmation. Les modeles produits 
lors de l'analyse decrivent ce que doitfaire le systeme independamment de la facon dont on 
va le realiser. La conception va permettre de decider comment realiser le systeme. La phase 
de conception est composee de deux etapes : 

• la conception du systeme ; 

• la conception des classes. 

Conception du systeme 

Au final, le logiciel va s'executer sur des ressources materielles (processeurs, memoire. . . ). Le 
concepteur du logiciel doit choisir les ressources adequates. Generalement, il est guide par 
les besoins du logiciel. Le choix ne peut pas se faire directement a partir des modeles d'ana- 
lyse, notamment pour les raisons suivantes : 

• Les ressources materielles sont limitees. 

• Les ressources materielles sont diverses, variees et souvent heterogenes. 

La principale limitation des ressources concerne les microprocesseurs des ordinateurs et les 
systemes d'exploitation qui les gerent. Ce sont des ressources partagees auxquelles peuvent 
acceder toutes les applications qui s'executent en meme temps sur une machine. Lors de 
l'etape d'analyse d'un logiciel, on fait la supposition que tous les objets disposent de res- 
sources illimitees. Or, au vu des ressources processeur limitees, il convient de decider, parmi 
toutes les methodes des classes du logiciel, lesquelles doivent s'executer sequentiellement, 
et lesquelles doivent le faire en parallele. Pour reperer les methodes concurrentes, on peut 
analyser les modeles des etats produits au moment de l'analyse. 

Le choix des ressources materielles doit etre guide par les besoins du logiciel. Une fois le 
choix fait, il faut s'adapter aux capacites des ressources. La principale difficulte reside dans 
leur grande diversite. Certains systemes d'exploitation ou certains langages de programma- 
tion par exemple, fonctionnent selon un mode evenementiel, d'autres sur un mode proce- 
dural, voire concurrent, etc. Le concepteur doit done choisir une strategic de controle pour 
son logiciel. De plus, si le logiciel est reparti sur plusieurs machines, la strategic de controle 
ne sera pas forcement la meme pour les parties du logiciel qui s'executent sur des machines 
differentes. UML n'est d'aucune aide pour choisir la strategic de controle. En revanche, il est 
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possible de decrire les parties d'un logiciel qui s'executent sur des materiels a l'aide des 
diagrammes de deploiement (voir l'annexe D). 

Au depart, le concepteur ne dispose que des modeles issus de l'analyse, c'est-a-dire des 
diagrammes de classes, des etats-transitions, des sequences, etc. Or, le passage des modeles 
de l'analyse au diagramme de deploiement est loin d'etre immediat. Le concepteur pro- 
cede par etapes. Tout d'abord, le systeme (dans notre cas, un systeme logiciel) est decom- 
pose en sous-systemes. La partition du systeme doit permettre de regrouper dans un sous- 
systeme des classes, des associations, des operations, des evenements, etc., qui collaborent 
aux memes fonctionnalites, ou dont les contraintes techniques les destinent a s'executer 
sur les memes ressources. UML ne donne pas d'indication sur les criteres a prendre en 
compte pour partitionner un systeme, mais permet simplement de representer des sous- 
systemes. Apres que le systeme a ete decompose en sous-systemes, les etapes suivantes 
consistent a : 

• reperer les objets qui s'executent concurremment ; 

• allouer les sous-systemes a des materiels ; 

• choisir sur quel(s) support(s) stacker les donnees (bases de donnees, fichiers, etc.) ; 

• identifier les ressources necessaires (processeurs, disques, ecrans, claviers, etc.) ; 

• choisir une (ou plusieurs) strategie(s) de controle du logiciel (evenementielle, procedu- 
rale, etc.) ; 

• s'assurer du bon fonctionnement du logiciel dans des conditions limites (comment 
l'initialiser, l'arreter, gerer les erreurs, etc.). 

Remarque 

UML n'est d'aucune utilite dans les quatre dernieres etapes. 




Conception des classes 

A ce stade de la conception, le systeme a ete decoupe en sous-systemes et les ressources utiles 
au logiciel ont ete choisies. La derniere etape de la conception avant l'implementation 
consiste a definir et a appliquer une strategic pour combler la « distance » qui separe les 
operations des classes des ressources choisies. La technique utilisee ici rejoint l'approche 
fonctionnelle du developpement logiciel. Le concepteur precede par decomposition des 
fonctions en sous-fonctions, puis choisit des algorithmes pour realiser ces fonctions. Les 
choix de conception faits a ce moment-la sont plutot techniques, mais ils doivent toujours 
etre guides par les cas d'utilisation. Les diagrammes d'activite d'UML permettent de decrire 
les algorithmes complexes, et les classeurs structures sont utiles lors de la decomposition des 
classes et des operations des classes. Les algorithmes sont choisis principalement pour les 
performances qu'ils offrent. Le concepteur peut aussi etre amene a optimiser Faeces aux 
attributs des classes en ajoutant de nouvelles associations au diagramme de classes. 



Conclusion 

Dans ce chapitre, nous avons rassemble tous les elements de modelisation qui ont ete 
abordes dans cet ouvrage et presente un processus visant a modeliser un systeme logiciel. 
Ce processus general pourra etre adapte a des projets specifiques. 
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Etude de cas 



Enonce 



du probleme 



Le probleme concerne un projet de developpement d'un logiciel. La premiere etape du cycle 
de vie du projet, la planification, a permis de definir le probleme, d'etablir un calendrier, et 
de verifier la faisabilite du projet. Notre description commence a l'etape d'analyse. 

Cette section contient l'essentiel de l'etude de cas. Des informations complementaires sont 
disponibles sur le site http://www.pearsoneducation.fr. 



Le but de ce projet est de developper un logiciel qui gere la distribution de carburant dans 
une station-service. 

Le fonctionnement de la distribution de l'essence est le suivant : avant de pouvoir etre 
utilisee par un client, la pompe doit etre armee par le pompiste. Mais ce n'est que lorsque le 
client appuie sur la gachette du pistolet de distribution que l'essence est pompee. Si le pis- 
tolet est dans son etui de rangement, et si Ton appuie sur la gachette, l'essence n'est pas 
pompee. La prise d'essence est terminee quand le client remet le pistolet dans son etui. 

II existe quatre types de carburants : diesel, sans plomb avec 98 comme indice d'octane, sans 
plomb avec 95 pour indice d'octane, plombe. 

Le paiement peut s'effectuer en especes, par cheque ou par carte bancaire. En fin de journee, 
les transactions sont archivees. 

Les pompes ne peuvent etre armees que si le niveau des cuves depasse 5 % de leurs capacites 
maximales. 



Le contexte technique du logiciel est impose (figure 6.3). Le logiciel doit s'executer sur une 
unite centrale a laquelle sont relies : 

• des capteurs pour mesurer le niveau de carburant dans les cuves ; 

• des pompes qui puisent le carburant dans les cuves ; 

• le pupitre du pompiste (ecran et clavier) ; 

• un systeme cles en main de paiement par carte bancaire. 



Description 



DU PROBLEME 



Contexte technique du systeme 
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Figure 6.3 

Contexte technique 
du logiciel (ce 
diagramme n'est 
pas un diagramme 
UML). 



Cuves a carburant 6 ^ 



Pompe 1 



Pupitre pompiste 



I 



Unite centrale 



1 



T 



Banque 



2 



Systeme de paiement 
par carte bancaire 



Pompe n 



SP98 Super SP95 Diesel SP98 Super SP95 Diesel 



Diagramme de deployment des peripheriques du systeme 



Pour preciser le contexte technique du systeme, il est parfois utile de montrer un exemple de 
solution. Lexemple doit etre donne a titre purement indicatif et la solution finale pourra 
etre differente. Pour que l'analyse, qui n'a pas encore debute, ne soit pas biaisee, il faut cepen- 
dant veiller a ne donner aucune consigne de conception (architecture interne, structure de 
donnees, algorithmes, etc.). 

La figure 6.4 presente le diagramme de deploiement des peripheriques du systeme informa- 
tique de la station-service. Le systeme informatique, quand il sera deploye, s'executera sur le 
nceud « unite centrale ». A ce stade du projet, il s'agit d'une boite noire. Outre Turfite centrale, 
on retrouve sur ce diagramme les peripheriques de la figure 6.3. 



Figure 6.4 

Diagramme 
de deploiement 
des peripheriques 
du systeme. 



« clavier » 
clavier du 
pompiste 



T 




« ecran » 
ecran du pompiste 



Peripherique 
de gestion des 
cuves 



« unite centrale » 
Systeme informatique de la station-service 

~7 I 



T 




Peripherique de 
paiement par carte 
bancaire 



« disque » 
Base de donnees 



Peripherique 
de gestion des 
pompes 




On suppose que les peripheriques materiels (de gestion des cuves, des pompes et du terminal 
de paiement) sont pilotes par des composants existants. La figure 6.5 montre uniquement 
les composants qui pilotent une pompe : les deux premiers permettent de connaitre respec- 
tivement les etats des gachettes (appuyees ou relachees) et des pistolets ; le troisieme fournit 
une interface (InterfacePompe) permettant d'armer et d'activer la pompe. 
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Figure 6.5 

Les composants qui 
gerent une pompe. 
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Informations transmises : 

- gachette appuyee, 

- gachette relachee. 



Informations transmises : 

- numero de pompe, 

- type carburant choisi, 

- pistolet decroche, 

- pistolet raccroche. 



« interface » 
InterfacePompe 



armer : booleen 
desarmer : booleen 

activer : booleen 
desactiver : booleen 



Analyse du domaine de ^application 

Nous choisissons arbitrairement de commencer par l'analyse du domaine de l'application. 
II est possible d'avoir une lecture differente et de commencer par l'analyse de l'application 
(voir plus loin dans ce chapitre). La seule contrainte, c'est qu'il faut mener ces deux analyses 
de facon independante. Le premier modele du domaine a produire est celui des classes. 
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MODELE DES CLASSES DU DOMAINE 



1. Trouvez les classes qui font partie du domaine de l'application. 

2. Trouvez les associations entre les classes. 

3. Trouvez les attributs des classes. 

4. Organisez et simplifiez le diagramme en utilisant l'heritage. Testez les chemins d'acces 
aux classes. Iterez et affinez le modele. 

5. Regroupez des classes dans des paquetages. 

1. Avant de dresser une liste de classes, commencons par delimiter le domaine de l'applica- 
tion. Le contexte technique du logiciel a concevoir impose d'utiliser des peripheriques 
materiels qui interagissent avec notre logiciel via des capteurs (les detecteurs de niveau 
des cuves, par exemple). Notre but n'est pas de concevoir ces peripheriques mais de les 
modeliser arm de pouvoir les piloter. Bien entendu, un modele du domaine doit depen- 
dre le moins possible des applications qui vont s'appuyer sur lui. Plus le nombre dupli- 
cations qui peuvent etre construites a partir d'un seul modele du domaine est eleve, et 
meilleur est ce modele. Cependant, dans notre cas, le domaine est clairement limite a une 
station-service : notre modele n'est pas destine a l'alimentation en carburant de voitures 
de course pendant une competition, ni au remplissage des reservoirs d'un avion. 

L'analyse de domaine est realisee avec un expert. II connait les peripheriques qui gerent la 
distribution d'essence, et notamment les capteurs et les actionneurs qui les controlent. 
Commencons par en dresser une liste exhaustive : 

• capteurs de niveau des cuves ; 

• dispositifs de pompage qui pompent le carburant dans les cuves ; 

• gachettes des pistolets de distribution de carburant qui controlent les dispositifs de pom- 
page ; 

• capteurs de presence des pistolets dans les etuis de rangement. 

Le domaine ainsi delimite, nous pouvons en commencer l'analyse. L' etude de la descrip- 
tion du probleme donne une premiere liste de classes candidates : Pistolet, Gachette, 
Pompe, Etui, Carburant, Cuve, Client, Transaction, Archive. 

La notion de pompe est centrale dans la prise de carburant, mais que recouvre-t-elle 
exactement ? Est-ce l'appareil auquel fait face un client et qui contient un ensemble de 
pistolets, de gachettes, d'etuis, etc., ou est-ce la pompe qui puise le carburant dans les 
cuves ? L'etude des capteurs et des actionneurs reproduite precedemment mentionne un 
« dispositif de pompage qui pompe le carburant dans les cuves ». C'est avant tout le dis- 
positif de pompage que nous devons piloter (et done modeliser). Pour lever l'ambigu'ite 
pesant sur le mot pompe, nous choisissons d'utiliser DispositifDePompage a la place. 
L'ensemble des pistolets, des gachettes et des etuis auquel fait face un client est appele 
EnsemblePompe. 

Le dispositif de pompage est controle par un pistolet, une gachette et un etui, d'ou les 
noms de classes Pistolet, Gachette et Etui. 

La notion de cuve est importante dans notre domaine. Elle permet, notamment, de reali- 
ser la contrainte sur l'armement d'une pompe. Elle est modelisee par une classe appelee 
Cuve. La cuve contient du carburant. Carburant constitue egalement un bon nom pour 
une classe. 
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Client, transaction et archive n'ont pas encore ete traites. Pour Fapplication que nous 
allons concevoir, un client est celui qui se sert de l'essence : c'est un concept clair et non 
ambigu pour Fapplication. Qu'en est-il du domaine de Fapplication ? Quel concept du 
« metier » de la distribution de carburant voulons-nous cerner ? Le client prend de 
l'essence. C'est done plus la prise d'essence, l'essence delivree (la quantite, le type de car- 
burant, etc.) qui nous interesse que le client en tant que tel. En ce qui concerne ce dernier, 
nous voulons plutot savoir quel type de paiement il a effectue (en especes, par cheque ou 
par carte bancaire), et eventuellement, conserver le numero d'immatriculation de sa 
voiture. Nous sommes done en presence de deux concepts distincts. Le premier, qui 
correspond a l'essence delivree, est modelise par une classe appelee PriseDeCarburant. 
La prise de carburant n'englobe pas le type de paiement. Elle est liee au dispositif de 
pompage qui est au cceur de notre domaine. Le type de paiement est lie a un client. Pour 
la distribution d'essence a des particuliers, le paiement fait partie du domaine de Fappli- 
cation. Resumons cette notion par le mot-cle Transaction-Client. Le dernier substantif que 
nous n'avons pas encore aborde est archive. Les transactions doivent etre archivees quo- 
tidiennement. Pour qu'il n'y ait pas d'ambiguite, renommons Fensemble des transactions 
quotidiennes TransactionsDuJour. 

La liste des classes candidates est a present la suivante : Pistolet, Gdchette, DispositifDe- 
Pompage, EnsemblePompe, Etui, Carburant, Cuve, PriseDeCarburant, TransactionClient, 
TransactionsDuJour. 

Afin de definir clairement chaque terme, un dictionnaire a ete redige. Void un extrait : 



Carburant 


Essence distribute par la station-service. Le carburant peut etre de 
plusieurs types (sans plomb 98, sans plomb 95, super et diesel). 


Cuve 


Conteneur du carburant de la station-service. 11 y a une cuve par 
type de carburant. 






DispositifDePompage 


Appareil qui pompe le carburant dans les cuves. 


TransactionClient 


Contient toutes les informations concernant le paiement d'un 
client, incluant le montant, la date et Fheure de la transaction. 


TransactionsDuJour 


L' ensemble des transactions realisees en une journee. 



Remarque 

Tous les termes lies au domaine ou d I'application doivent etre consignes dans des diction- 
naires, mais pour des raisons de place, nous ne les avons pas tous reproduits. 

I . I 

2. Un premier diagramme de classes contenant des associations est presente a la figure 6.6. 
Notre objectif premier est de modeliser Forganisation des peripheriques afin de les 
controler. 

Le modele s'articule autour du dispositif de pompage. C'est la gachette qui controle Facti- 
vation du dispositif de pompage. D'ou Fassociation entre les classes Gdchette et Dispositif- 
DePompage. Ce dispositif pompe le carburant dans une cuve (a noter que Fassociation 
de 1 vers plusieurs entre les classes Cuve et DispositifDePompage indique que plusieurs 
pompes puisent le carburant dans une meme cuve). 



Chap 



La gachette ne peut declencher le pompage que si le pistolet qui la contient est dans son 
etui. C'est l'etat d'un capteur qui indique si le pistolet est dans son etui ou pas. Pour 
modeliser cette information, nous etablissons une association ayant la multiplicity 0 ou 1 
entre les classes Pistolet et Etui. 

La prise de carburant relie les classes DispositifDePompage, Carburant et Transaction- 
Client. 



Figure 6.6 

Premiere version 
du diagramme de 
classes du domaine. 



EnsemblePompe 





1..* 


Pistolet 




0..1 








Etui 





controle 
activation 



DispositifDePompage 



PriseDeCarburant 



TransactionsDuJ our 



TransactionClient 
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La navigabilite des associations n'est pas prise en compte a ce stade de l'analyse. 

3. La plupart des attributs sont des booleens qui refletent l'etat des capteurs physiques 
(figure 6.7) : le pistolet est dans son etui, la gachette est appuyee, le dispositif de pompage 
est arme ou actif (il est actif quand le pompage a lieu). 

Si le pistolet possede un booleen qui indique s'il est ou non dans son etui, la classe Etui 
devient superflue : elle est supprimee du modele. 

La classe Cuve est caracterisee par son niveau de carburant. La classe Carburant contient 
le prix au litre ainsi que le type de carburant (sans plomb 98, etc.). 

La classe TransactionClient recense l'ensemble des donnees caracterisant le paiement par 
un client : le type de paiement (especes, carte bancaire ou cheque), le montant ainsi que 
la date de la transaction. La quantite d'essence prise qui permet de calculer le montant est 
detenue par la classe PriseDeCarburant. 
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Figure 6.7 

Version du 
diagramme de 
classes du domaine 
incluant les attributs. 
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« Enumeration » 
TypeCarburant 



sansPlomb98 
sansPlomb95 

super 

diesel 



4. Les differents types de carburants peuvent etre modelises en creant des classes qui heritent 
de la classe Carburant (figure 6.8). 



Figure 6.8 

Moderation des 
types de carburants 
par un heritage. 




Cependant, nous avons utilise une enumeration a la place de l'heritage, car un heritage ne 
se justifie que si au moins une classe derivee possede un attribut, une association ou une 
methode specifique, ce qui n'est pas le cas ici. Le diagramme de classes de la figure 6.10 
contient une enumeration appelee TypeCarburant qui est utilisee pour typer l'attribut 
typeCarburant de la classe Carburant. 

Le client peut choisir parmi trois modes de paiement : par carte bancaire, en especes ou 
par cheque. Or, jusqu'a present, nous ne disposons, dans notre modele, que d'une seule 
classe pour gerer le paiement : TransactionClient (figure 6.7). Le paiement par carte ban- 
caire est particulier car la transaction doit etre validee aupres de la banque. Si le client 
souhaite payer par cheque, il doit donner au pompiste un identifiant, son numero de 
carte d'identite, par exemple. Ces particularites incitent a transformer la classe Transac- 
tionClient en une classe de base dont heritent trois classes (figure 6.9) : TransactionEn- 
Especes, TransactionBancaire et TransactionParCheque. La classe TransactionClient est 
abstraite car elle possede l'operation abstraite payer. Celle-ci sera implementee dans les 
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Figure 6.9 

Un heritage 
pour modeliser 
les transactions. 



Chapitre 



classes derivees et permettra ainsi de particulariser le paiement. L'attribut identifiant- 
Client a ete ajoute a la classe TransactionParCheque pour que celle-ci puisse conserver 
Fidentifiant d'un client payant par cheque. 



TransactionClient {abstract} 



date : Date 
montant : reel 



payer {abstract} 

2\ 



TransactionEnEspeces 



payer 



TransactionBancaire 



payer 



TransactionParCheque 



identifiantClient : entier 



payer 



La technique de Fheritage permet d'etendre le domaine au plus grand nombre d'applica- 
tions possibles. Or, il est rare aujourd'hui qu'une station-service vende uniquement du 
carburant. En observant le graphe d'heritage de la figure 6.9, on s'apercoit que les trans- 
actions des clients peuvent s'appliquer a la vente de n'importe quel produit ou service. Ce 
qui caracterise la vente de carburant, c'est l'association etablie entre les classes Transac- 
tionClient et PriseDeCarburant. Pour generaliser la vente a d'autres services, une nouvelle 
classe appelee Service est creee (pour ne pas trop sortir du cadre de cette etude, la vente de 
produits n'est pas prise en compte). La prise de carburant devient alors un service, et la 
classe PriseDeCarburant herite de la classe Service (figure 6.10). Pour Finstant, aucun 
service supplemental n'a ete ajoute au modele, mais si, a l'avenir, un service d'entretien 
de vehicules venait a etre cree, le graphe d'heritage des services serait pret a recevoir une 
classe appelee EntretienVehicule. 

Pour tester en profondeur les chemins d'acces aux classes, vous pouvez definir des reque- 
tes utilisant le langage OCL. Une autre technique consiste a employer des diagrammes 
d'interaction (de sequence ou de communication) pour montrer comment des objets, 
instances des classes, collaborent a la realisation des cas d'utilisation. Mais avant d'utiliser 
les interactions, il faut avoir developpe le modele de l'analyse de l'application. Ce que 
nous ferons juste apres avoir regroupe les classes en paquetages et bati le modele des etats 
du domaine. 

5. A la figure 6.10, deux ensembles de classes correspondant a deux fonctionnalites de la 
station-service apparaissent : un premier ensemble concerne la prise de carburant (il 
regroupe les classes EnsemblePompe, Pistolet, Gdchette, DispositifDePompage, Cuve, 
Carburant, PriseDeCarburant et Service), et un deuxieme a trait aux transactions (Trans- 
actionsDuJour, TransactionClient, TransactionEnEspeces, TransactionBancaire, Transac- 
tion-ParCheque, PriseDeCarburant et Service). Les classes liees a la prise de carburant sont 
regroupees dans un paquetage appele ServiceCarburant, tandis que les classes relatives 
aux transactions sont incluses dans un paquetage appele Transactions (figure 6.11). 
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Figure 6.10 

Diagramme de 
classes du domaine. 



Pistolet 



dansEtui : booleen 



I 



Gachette 



appuyee : booleen 



controle 
activation 



Pompe carburant dans 



EnsemblePompe 



numeroPompe : entier 



Service 



{ ordonnees par date } 



Trans actions Du Jour 



Pistolet 



archiver() 



0..* 



3E 



DispositifDePompage 



arme : booleen 
actif : booleen 



PriseDe Carburant 



quantiteCarburant : reel 



debit e 



Trans actionClient {abstract} 



date : date 
montant : reel 



payer {abstract} 



Cuve 



niveau : entier 



Carburant 



prix : reel 
typeCarburant : TypeCarburant 



« Enumeration >: 
TypeCarburant 



sansPlomb98 
sansPlomb95 

super 

diesel 



TransactionEnEspeces 



payer( ) 



TransactionBancaire 



payer( ) 



TransactionParCheque 



idenlifiantClient : entier 



payer( ) 



Figure 6.1 1 

Paquetages du 
modele du domaine. 





Remarque 

II faut essayer de limiter les dependances entre paquetages car cela facilite la reutilisabilite 
separee des paquetages dans d'autres projets. II y a dependance entre deux paquetages 
quand une association existe entre deux classes appartenant a deux paquetages differents. 
Si I'association est bidirectionnelle, la dependance Test aussi (figure 6.12). 
Dans ce cas, il est peut-etre possible de limiter I'association a un seul sens (ce qui supprime 
une des deux dependances entre les paquetages). 

II ne faut pas oublier non plus que la dependance entre deux paquetages depend aussi du 
nombre de messages qui circulent sur I'association. Plus le nombre de messages est eleve, 
plus la dependance est forte. Si ce nombre est trop important, il faut peut-etre revoir la repar- 
tition des classes entre les paquetages afin que I'association qui est en cause ne les relie plus. 
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Chapitre 



Figure 6.1 2 

Double dependance 
entre paquetages. 



F I Q U TG 6 13 

Simple dependance 
entre paquetages. 




MODELE DES ETATS DU DOMAIN E 



Le modele des classes du domaine est a present complet. II n'a cependant pas ete valide par 
d'autres modeles qui vont l'eclairer sous un nouveau jour. Apres avoir construit le dia- 
gramme de classes du domaine, il faut a present etudier chaque classe separement et reperer 
celles qui engendrent des objets au cycle de vie complexe. Pour ces classes particulieres, il 
faut construire un diagramme d'etats-transitions. 



1. Identifiez des classes du domaine ayant des etats complexes. 

2. Pour chaque classe ayant des etats complexes : 

- definissez les etats ; 

- trouvez les evenements ; 

- construisez les diagrammes d'etats. 



1. Seules les classes DispositifDePompage et TransactionClient (avec ses classes derivees) ont 
des etats complexes. 

2. Un diagramme d'etat debute au moment oil une instance est creee. Etant donne que la 
classe TransactionClient contient une operation abstraite (payer), elle ne peut pas etre 
instanciee. Ses classes derivees (TransactionEnEspeces, TransactionBancaire et Transaction- 
ParCheque) implementent l'operation payer, ce qui leur permet d'etre instanciables. 
L'instanciation intervient des que le pompiste selectionne le mode de paiement choisi par 
le client. 

II faut a present imaginer des etats. L'etat d'un objet est souvent caracterise par la valeur 
instantanee de ses attributs et de ses liens vers d'autres objets. On en deduit plusieurs 
etats possibles : 

• type de paiement choisi ; 

• payee ; 

• archivee. 

Les evenements qui declenchent des transitions vers ces etats sont : 

• choix du mode de paiement ; 

• valider la transaction. 
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A partir des etats et des evenements precedents, le diagramme d'etats-transitions est 
construit. 



Figure 6.14 

Diagramme des 
etats-transitions 
pour la classe 
TransactionClient. 



1 



type paiement 
choisi 



annuler 



valider paiement 



paiement valide 



archiver 



archive 



Remarque 




Le modele du domaine doit dependre le moins possible des applications qui vont reposer 
sur lui. II faut done essayer, quand on construit ce modele, de ne pas y faire intervenir des 
considerations liees d une application particuliere. II est done important de commencer par 
trouver les etats avant les evenements. Commencer par chercher les evenements conduit d 
reflechir d la maniere d'utiliser un systeme, ce qui revient d imaginer une application parti- 
culiere. 



Interessons-nous a present a la deuxieme classe qui engendre des objets ayant des etats com- 
plexes : la classe DispositifDePompage. A quel moment des instances doivent-elles etre 
creees ? C'est difficile a dire en l'etat actuel de l'analyse : en effet, le dispositif de pompage en 
tant que peripherique materiel existe independamment du logiciel qui va le piloter, mais 
qu'en est-il des instances de la classe DispositifDePompage ? Quand le client arrive pour 
prendre de l'essence, il a plusieurs pistolets (un par type de carburant) a sa disposition. 
Des qu'il a pris un pistolet, le type de carburant qu'il desire est connu. On sait done dans 
quelle cuve il faut puiser du carburant. Chaque cuve a des pompes particulieres que notre 
logiciel va devoir piloter. Le pilotage commence done des que le client decroche un pistolet 
(il faut alors armer le dispositif de pompage). L'instance ne doit pas forcement etre creee a 
ce moment-la car cela a peut-etre deja ete fait auparavant. Comme nous ne pouvons pas le 
savoir pour l'instant, nous ne precisons pas dans le diagramme suivant l'evenement qui 
instancie un dispositif de pompage. 

Pour un dispositif de pompage, les etats possibles sont les suivants : 

• arme ou desarme en fonction des actions du pompiste ; 

• bloque ou debloque selon que le pistolet est range ou non ; 

• actif ou inactif selon que l'essence est en train d'etre pompee ou non. 

A l'aide des etats et des evenements ci-dessus, on en deduit le diagramme d'etats-transitions 
de la figure 6.15. Notons que quand le client raccroche le pistolet, la pompe est automati- 
quement desarmee. 
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Figure 6.1 5 

Diagramme des etats- 
transitions de la classe 
DispositifDePompage. 



1 



desarme 



A 



raccrocher pistolet 



bloque 



inactif 



decrocher pistolet 



debloque 



pression 
gachette 



depression 
gachette 



actif 



Analyse de ^application 

L'analyse de l'application commence par 1' etude des cas d' utilisation. Ce modele represente le 
systeme informatique de la station-service vu par les acteurs. II est construit independam- 
ment du modele du domaine de l'application. Par la suite, ces deux modeles seront confrontes 
pour verifier que les classes du domaine permettent de realiser les cas d'utilisation. L'analyse 
complete de l'application se fait en batissant trois modeles : 

• le modele des interactions de l'application ; 

• le modele des classes de l'application ; 

• le modele des etats de l'application. 

La phase d'analyse se conclut par l'ajout d'operations aux classes. 

Modele des interactions de l'application 



1. Determinez les limites du systeme. Trouvez les acteurs. Trouvez les cas d'utilisation. 
Construisez le diagramme de cas d'utilisation. 

2. Preparez les scenarios pour decrire les cas. Ajoutez des sequences alternatives et des 
sequences d'exceptions aux scenarios. Preparez des diagrammes d'activite pour des cas 
d'utilisation complexes. 

3. Verifiez la coherence entre le modele des classes du domaine et celui de l'application. 



1. Les quatre premieres questions ont ete traitees dans la partie exercices du chapitre 1. Vous 
y trouverez des explications sur la demarche qui a permis d'aboutir au diagramme pre- 
sente a la figure 6.16. 
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Figure 6.1 6 

Diagramme de cas 
d'utilisation de la 
station-service. 



Capteur niveau cuve 
pour armemcnt 



Capteur niveau cuve 
pour remplissage 




Pompiste 



Banque 



Tous les soirs a minuit 




Timer 



2. Les cas d'utilisation doivent etre decrits sous forme textuelle comme indique au chapitre 1. 
Certains peuvent etre decrits a Faide de diagrammes de sequence ou par des diagrammes 
d'activite. Pour chaque cas, il faut definir une sequence nominale ainsi que des sequences 
alternatives et d'exceptions. Pour des raisons de place, la description textuelle des cas et 
les sequences alternatives et d'exceptions ne sont pas presentees. 

Un cas d'utilisation est declenche quand un evenement survient. Le dictionnaire suivant 
liste les evenements qui initient les cas d'utilisation. Comme nous l'avons vu au chapitre 
1, les evenements peuvent etre classes en trois categories : 

• les evenements externes ; 

• les evenements temporels ; 

• les evenements d'etats. 
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Chapitre 



II est minuit a l'horloge 
systeme 

Choix du mode de paie- 
ment 

Decrochage d'un pistolet 



Demande armement 

pompe 

Demande niveau dans 
cuve pour armement 

Niveau dans cuve pour 
remplissage atteint 

Encaissement (pompe, 
typeCarburant) 



Evenement temporel qui declenche le cas « Archiver les trans- 
actions ». C'est aussi un evenement externe car le temps est 
considere comme un acteur : acteur Timer. 

Evenement externe produit par l'acteur Pompiste qui declenche 
un des trois cas particuliers de paiement : « Payer par carte 
bancaire », « Payer en especes » et « Payer par cheque ». 

Evenement externe produit l'acteur Client qui declenche le cas 
« Se servir ». 

Evenement externe produit par l'acteur Pompiste qui declenche 
le cas « Armer Pompe ». 

Evenement d'etat, car produit lors du deroulement du cas 
« Se servir », qui declenche le cas « Verifier niveau cuve pour 
armement ». 

Evenement externe produit par l'acteur « Capteur niveau cuve 
pour remplissage » qui declenche le cas « Verifier niveau cuve 
pour remplissage ». 

Evenement externe produit par l'acteur Pompiste qui declenche 
le cas « payer ». 



On remarque sur le diagramme de la figure 6.16 que le paiement intervient apres que le 
client a pris de l'essence. En situation reelle, il faudrait s'inquieter de l'evolutivite de notre 
application et considerer le cas ou le paiement interviendrait avant. II faudrait aussi offrir 
la possibilite au client de payer lui-meme, directement avec une carte de credit dans le ter- 
minal de la pompe, sans l'intervention du pompiste. La figure 6.17 montre comment le 
diagramme de cas d' utilisation peut etre transforme pour que le paiement puisse intervenir 
avant que le client prenne de l'essence. Dans la suite de cette etude de cas, nous revenons a 
la situation initiale (cas ou le client paye apres avoir pris du carburant). 
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Scenario nominal pour « Se servir » du carburant. La figure 6.18 etablit le scenario nominal 
du cas d'utilisation « Se servir » du carburant. A noter la boucle qui indique que le client 
peut appuyer et relacher plusieurs fois la gachette avant de reposer le pistolet. II est egale- 
ment fait reference a un diagramme appele ArmerPompe. On indique ainsi que l'armement 
est inclus dans la prise d'essence. 



Figure 6.1 8 

Scenario nominal 
du cas « Se servir ». 



sd Se servir 



7 



Client 



Station-service 



Decrochage d'un pistolet i 



ref 



ArmerPompe 



loop i X 



\ pistolet hors etui ] 

Appui sur la gachette 



'Affiche quantite essence + montantj 



Relachement de la gachette 



Raccrochage du pistolet 



Desarmer 
pompe 



La figure 6.19 donne le scenario nominal pour le cas « Armer Pompe ». La verification du 
niveau des cuves pour l'armement y est incluse. De plus, on verifie que plusieurs pistolets 
n'ont pas ete decroches. 
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Figure 6.1 9 

Scenario nominal 
du cas « Armer 
pompe ». 



sd ArmerPompe 



7 



: Station service 



Pompiste 



Affiche numero de pompe + 
type essence prise 

Demande armement pompe 



Tester si un autre pistolet 
n'est pas decroche 



ref 



7 



VerifierNiveauCuvePour Armement 



<- 



RAZ compteur volume 



et montant + prix du litre 
Affiche confirmation armement 



Le scenario nominal pour le cas « Verifier niveau cuve pour armement » est donne a la 
figure 6.20. 



Figure 6.20 

Scenario nominal 
du cas « Verifier 
niveau cuve pour 
armement ». 



sd VerifierNiveauCuvePourArmement 



: Station service 



Demande niveau dans cuve pour armement 



Niveau dans cuve pour armement OK 



Capteur niveau 
pour armement 
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_ 



Remarque 




Le diagramme de cas d'utilisation detaille de maniere tres precise les fonctions de la sta- 
tion-service (on y voit I'armement ainsi que la verification du niveau des cuves). II eut ete 
possible de decrire le systeme plus sommairement comme le montre la figure 6.2 1 . Malgre 
ce changement d'echelle, le scenario pour se servir de I'essence ne change pas. La figure 
6.22 le reproduit. On y retrouve superposees les figures 6.18, 6.19 et 6.20, qui repre- 
sented la station-service, avec plus de details. Ceci denote I'importance tout relative des 
relations d'inclusion, d'extension et de generalisation qui peuvent agrementer un diagramme 
de cas d'utilisation. D'ailleurs, certains modelisateurs ignorent dans un premier temps les 
relations entre les cas, et etablissent d'abord les scenarios. 



Figure 6.21 

Diagramme de 
cas d'utilisation 
montrant moins 
de details. 



Capteur niveau cuve 
pour armement 



Capteur niveau cuve 
pour remplissage 




Pompiste 



Banque 



Timer 
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Chapitre 



Figure 6.22 

Scenario nominal 
des cas « Se servir », 
« Armer pompe » 
et « Verifier 
niveau cuve pour 
armement ». 



sd Se servir + Armer pompe + Verifier niveau cuve pour armement ~~\ 



: Statioil service 



Client 



Decrochage d'un pistolet 



sd 



ArmerPompe } 



Pompiste 
I 

I 



Capteur niveau 
pour armement 



Affiche numero de pompe + 

type essence pris | 
I 



Demande armement pompe 



I 



I 

Tester si un autre pistolet n'est pps decoche 
I 
I 



P 



sd VerifierNiveauCuvePour Armement 



7 



t 



Demande niveau dans cuVe pour armement 



Niveau dans cuve pour armement OK 



RAZ compteur volume 
et montant + prix du litre 



Affiche confirmation armement 



loop 



[ pistolet pors etui ] 



Appui sur la gachette 



Affiche quantite essence + montant 



Relachement de la gachette 



Raccrochage du pistolet 



0 



Desarmer pompe 



Scenario nominal du cas « Payer ». Interessons-nous a present au cas du paiement. Le 
diagramme de cas d' utilisation de la figure 6.16 indique une relation de generalisation entre 
les cas « Payer par carte bancaire », « Payer par cheque », « Payer en especes » et « Payer ». 
On signifie ainsi que le paiement commence a se derouler uniformement puis se specialise 
en trois cas particuliers. La divergence de traitement intervient quand le pompiste choisit 
le mode de paiement conformement a la demande du client. Le diagramme montre alors 
une reference a un comportement polymorphe, TransactionClient.payer, qui correspond a 
Finvocation de reoperation payer de la classe TransactionClient figurant dans le diagramme 
de classes du domaine (figure 6.10). 

A noter aussi que le paiement debute quand le pompiste selectionne la pompe et le type de 
carburant dont s'est servi le client. 

La figure 6.23 illustre le scenario nominal du cas « payer ». On remarque aussi la reference 
faite a TransactionClient.payer. On indique ainsi que cette partie du scenario peut varier en 
fonction du mode choisi. 
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Figure 6.23 

Scenario nominal 
pour le cas 
« payer ». 



sd payer 



: Station-service 



Pompiste 

encaissement (pompe, typeCarburant) [ 
Affiche montant a payer 
Choix du mode de paiement 



ref 



7 



TransactionClient.payer 



3. La verification doit etre minutieuse : il s'agit d'etudier attentivement tous les scenarios en 
verifiant si les classes possedent tous les attributs et les chemins (les associations) neces- 
saires pour y acceder. La verification etant fastidieuse, elle n'a pas ete reproduite ici. 



MODELE DES CLASSES DE L' APPLICATION 



Les classes que nous avons decouvertes jusqu'a present sont issues du domaine de l'applica- 
tion. Elles sont a priori valables pour toutes les applications possibles dans le cadre d'une 
station-service. Cependant, elles ne sont pas suffisantes pour faire fonctionner une applica- 
tion particuliere. Par exemple, quand le pompiste interagit avec les classes du domaine via 
un terminal, un ensemble de classes supplementaires doit realiser des conversions de don- 
nees, afin de traduire les attributs des classes du domaine dans un format plus parlant pour 
le pompiste. 



Enonce 



1. Specifiez l'interface homme-machine. 

2. Definissez les classes a la peripheric du systeme. 

3. Definissez des classes pour controler le systeme. Controlez la coherence avec le modele 
des interactions. 



1. Pour specifier l'interface homme-machine, on en construit souvent une maquette 
(figure 6.24). Elle represente l'ecran principal auquel fait face le pompiste. II est compose 
de n zones, chacune appelee « Pompe i » (pour i allant de 1 a n). Chaque zone est consti- 
tute de quatre boutons qui permettent au pompiste de demander l'armement d'une 
pompe. Si le niveau d'essence dans les cuves est suffisant, la pompe est armee et le bouton 
correspondant reste enfonce. Si, au contraire, le niveau d'essence est insuffisant, le bou- 
ton de la pompe apparait en rouge. Des que le client a fini de se servir (il a raccroche le 
pistolet), le bouton de la pompe correspondant au type d'essence qu'il a pris clignote. 
Les boutons correspondant aux types d'essence choisis peuvent etre dans l'un des etats 
suivants : 
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Figure 6.24 

Ecran principal 
du terminal du 
pompiste. 



non enfonce (pompe desarmee) ; 
enfonce (pompe armee) ; 
rouge (armement impossible) ; 
clignotant (fin de prise de carburant). 



Pompe 1 



SansPlomb98 



SansPlomb95 



Diesel 



Super 



Chap 



Pompe n 



SansPlomb98 



SansPlomb95 



Diesel 



Super 



Des que le pompiste appuie sur un bouton clignotant, la zone de l'ecran correspondant a 
la pompe est remplacee par une zone servant au paiement (figure 6.25). 



Figure 6.25 

Ecran du terminal 
du pompiste tel qu'il 
apparaitau moment 
du paiement. 



Pompe 1 



Montant a payer : 30 euros 



Carte bancaire 



Cheque 



Especes 



Valider transaction 



Zone de l'ecran pour 
le paiement 



Pompe n 



SansPlomb98 



SansPlomb95 



Diesel 



Super 



Zone de l'ecran montrant 
des pompes desarmees 



Le pompiste peut choisir, via l'interface presentee a la figure 6.25, le type de paiement 
desire par le client (carte bancaire, cheque ou especes). Le bouton correspondant au 
mode de paiement choisi reste enfonce une fois selectionne. Le pompiste peut appuyer 
sur le bouton qui valide la transaction des que le client a paye. 

A partir de cette maquette la demarche consiste a batir un diagramme de classes qui doit 
refleter les echanges de donnees vehiculees entre cette interface et le cceur du logiciel. 
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La construction de ce diagramme suit les etapes habituelles suivantes : 

• dresser une liste de classes ; 

• trouver les associations entre les classes ; 

• etc. 

Ayant deja realise une etude similaire pour construire le diagramme de classes du domaine, 
l'etude des classes de l'interface utilisateur n'a pas ete reproduite. 

2. Notre logiciel doit etre interface avec des peripheriques materiels : des capteurs de niveau 
d'essence dans les cuves, un terminal de paiement, etc. Nous nous contenterons d'etudier 
les peripheriques qui gerent le niveau de carburant dans les cuves. Vous pourrez facile- 
ment en deduire les autres cas par analogic 

La figure 6.26 est extraite du diagramme de deploiement de la figure 6.4. Seuls les noeuds 
permettant la gestion des capteurs de niveau sont representes. Le peripherique de gestion 
des cuves est externe au systeme informatique de la station-service. II s'agit par exemple 
d'un border dont les extremites sont raccorde a un capteur de niveau et a 1' unite centrale. 
Un composant qui pilote le peripherique de gestion des cuves est charge de fournir a une 
classe du domaine le niveau du carburant via une interface (appele PiloteGestionCuve) . 



Figure 6.26 

Composant 
permettant 
d'acceder aux 
peripheriques de 
gestion des cuves. 





Peripherique de 


niveau 


gestion des cuves 



« unite centrale » 
Systeme informatique de la station 



: PiloteGestionCuve 



InterfaceCuve 



La figure 6.27 detaille l'interface InterfaceCuve et montre que la classe Cuve extraite du 
diagramme de classes de la figure 6.10 est cliente de cette interface. 



Figure 6.27 

La classe Cuve 
comme classe 
cliente de l'interface 
InterfaceCuve. 



« interface » 
InterfaceCuve 


< 


Cuve 




niveau : entier 


getNiveau : entier 









3. En plus des classes qui se trouvent a la peripheric d'un systeme et celles qui gerent l'inter- 
face homme-machine, un logiciel est constitue d'objets qui le controlent. Chaque objet 
controleur est dedie a une fonction particuliere. Dans notre cas, il s'agit de trois fonc- 
tions bien distinctes : la prise d'essence, le paiement et l'archivage des transactions. 
Pour commencer, tentons d'imaginer un objet qui puisse controler la prise d'essence. 

Session de prise d'essence. Des qu'un client decroche un pistolet, des instances des 
classes Pistolet, Gachette et DispositifDePompage sont pretes a activer le peripherique 
materiel qui pompe l'essence. Les etats des instances vont changer en fonction des actions 
des clients qui sont percues par le systeme au travers de capteurs. Si N clients prennent du 
carburant simultanement, il y aura N ensembles d'instances de Pistolet, de Gachette et de 
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Chapi 



DispositifDePompage. Pour controler ces trois instances, nous creons une classe appelee 
SessionDePriseDeCarburant. 

Le diagramme des objets presente a la figure 6.28 montre deux clients qui se servent du 
super 98 simultanement, chacun ayant sa propre session. 



Figure 6.28 

Diagramme d'objets 
qui montre deux 
sessions de prise 
d'essence. 



client 1 



session 1 



EnsemblePompe 1 



numero : entier = 1 



pistoletl 




priseDeCarburant 1 



carburant 



typeCarburant : TypeCarburant = sansPlomb98 



priseDeCarburant2 



EnsemblePompe2 



numero : entier = 2 



pistolet2 



gachette2 



pompel : DispositifDePompage 



Cuve 



pompe2 : DispositifDePompage 




Pour illustrer comment la session d'un client interagit avec les instances des classes Pistolet, 
Gdchette et DispositifDePompage, on definit une collaboration (figure 6.29). 



Une collaboration 
qui permet de 
montrer le 
deroulement 
d'une session de 
prise d'essence. 
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Cette collaboration est decrite plus en detail a la figure 6.30. Elle debute par la creation 
d'une session pour un client (instance de la classe SessionDePriseDeCarburant). Ensuite, des 
instances des classes Pistolet, Gachette et Pompe sont creees a leur tour. C'est la un parti pris. 
Nous avons en effet decide que ces instances n'existaient pas avant que le client decroche un 
pistolet. Une autre solution aurait consiste a disposer d'un pool d'objets prets a Femploi 
dans lequel on aurait pris a volonte des instances. Ce choix releve plutot de la conception 
que de l'analyse. Considerons-le comme un scenario de conception possible. La figure 6.30 
montre que les instances du pistolet et de la gachette sont detruites des que le client raccro- 
che le pistolet. Deux autres diagrammes servant a illustrer rarmement de la pompe et la 
prise du carburant sont references. 



Figure 6.30 

Interaction 
qui illustre la 
collaboration 
de la figure 6.29. 



sd SessionDePriseDeCarburant 



client : Client 

- Decrochage d'un pistolet 



pompiste : Pompiste 



session : SessionDePriseDeCarburant 



n 



pompe : DispositifDePompage 



gachette : Gachette 
i 1 — 



Affichc numero de pompe + type essence pris 



i i 



ref 



7 



ArmementPompe( client, pompiste, session, pompe ) 



ref 



7 



ActivationPompe( client, session, gachette, pompe ) 



Raccrochage du pistolet 



Affiche la fin de la prise d'essence 



Desarmer pompe 



3 



0 



L'armement de la pompe est illustre par le diagramme de la figure 6.31. On y voit que, avant 
d'armer la pompe, il faut tester si plusieurs pistolets ne sont pas decroches, puis verifier le 
niveau de la cuve. L'acteur CapteurNiveauPourArmement n'est pas represente ici : il est solli- 
cite implicitement par l'instance de la cuve. 



218 UML 2 



Chapi 



Figure 6.31 

Interaction qui 
illustre I'armement 
de la pompe. 



sd ArmemenlPompe( inout client : Client, inout pompiste : Pompiste, inout session : 
SessionDePriseDeCarbutaiit, inout pompe : DispositilDePompage) 



+autrePistolet : booleen 



pompe : DispositilDePompage 



session : SessionDePriseDeCarburant 



client : Client 



opt 



pompiste : Pompiste 
Demancle armement pompe 



ref J 




autrePistolet = 


TestAutrePistoIetPris 



[ autrePistolet == false ] 
Demancle 



Demande niveau dans 



cuve pour armement 



Niveau dans cuve 
> 

pour armement OK 



Z2' 



armement 



— 7T„ * 



RAZ eompteur volume 



et montant + prix du litre 



Affiche confirmation armement 
> 



La figure 6.31 fait reference au diagramme TestAutrePistoIetPris qui n'est pas represents (il 
s'agit simplement de demander a Finstance de YEnsemblePompe de verifier a l'aide d'une 
boucle qu'il n'y a pas plusieurs pistolets decroches). 

Le diagramme reproduit a la figure 6.32 detaille l'interaction ActivationPompe qui est refe- 
rencee a la figure 6.30. 



Figure 6.32 

Interaction qui 
illustre I'activation 
de la pompe. 



sd ActivationPompe( inout client : Client, inout session : SessionDePriseDeCarburant. inout gachette : Gachette. inout pompe : 
DispositifDePompage ) 



SessionDePriseDeCarburant gachette : Gachette pompe : DispositifDePompage 



client : Client 



loop ^ 



Appui sur la gachette 



^» — I Appuyer sur la gachette 



Relachement de la gachette 



I 

Relacher la gachette | 
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Session de paiement. Interessons-nous a present au paiement, et imaginons un objet pour 
le controler. Si la session de prise de carburant (instance de la classe SessionDePriseCarbu- 
rant) etait prolongee de maniere a englober le paiement, un objet pourrait alors controler le 
service de prise d'essence de « bout en bout », depuis le decrochage du pistolet jusqu'a la fin 
du paiement. Ce serait la session complete d'un client. Or, les classes du domaine ont ete 
partitionnees en deux paquetages pour accroitre la modularity du logiciel : un paquetage 
concerne la prise d'essence, l'autre le paiement. Une session client unique serait done parta- 
gee entre les deux paquetages (elle debuterait avec la prise de carburant pour se terminer par 
le paiement). C'est pourquoi nous avons decide de creer une nouvelle classe controleur 
(SessionDePaiement) qui se charge du paiement. 

La figure 6.33 etablit une collaboration entre des instances de PriseDeCarburant, de Trans- 
actionBancaire, de TransactionsDuJour et de SessionDePaiement. Les connecteurs entre les 
instances de PriseDeCarburant, de TransactionBancaire et de TransactionsDuJour represen- 
ted les associations du diagramme de classes du domaine (figure 6.10). 

Figure 6.33 

Collaboration pour 
le paiement. 

/ 

/ 

/ 

/ 
/ 
i 

\ 

\ 

\ 

\ 



La SessionDePaiement 




La figure 6.34 illustre les interactions au sein de la collaboration precedente. La session de 
paiement debute au moment ou le pompiste demande, via son terminal, a encaisser la prise 
d'essence relative a une pompe et a un type de carburant. Le montant de la transaction est 
calcule a l'aide du type de carburant (qui permet d' avoir le prix du litre) et de la quantite 
d'essence prise. Le diagramme se poursuit par le deroulement du scenario nominal de paie- 
ment par carte bancaire. Une instance de TransactionBancaire est creee le temps de realiser 
une transaction avec la banque. Des que le pompiste valide la transaction, celle-ci est 
ajoutee aux transactions du jour pour etre finalement detruite. La session de paiement se 
termine juste apres, par la destruction de l'instance correspondante. 
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Figure 6.34 

Interaction qui 
illustre comment le 
paiement est realise 
durant la session 
de paiement. 



sd payer par carte bancaire 



: TransactionsDuJour 



Banque 



opt 



: SessionDePriscDcCarbLiranl 



pompiste : Pompiste 
encaissement( pompe, typeCarburant ) 



session : SessionDePaicmeni 



demande la quantite pompee 



IT " 

quantite 



Calcul du Montant 



Afficher montant a payer 
Choix du mode de paiement 



[ paiement par carte bancaire] 



: TransactionBancaire 



validerTransaction( montant ) 



Transaction validee 



| Paiement effectue 

tr 



Valider transaction 



I Ajouter la transaction client 



Informe pompiste 



Valide la transaction 



Un gestionnaire pour l'archivage. Apres avoir trouve des objets controleurs pour assurer 
les fonctions de prise d'essence et de paiement, interessons-nous aux autres fonctions du 
logiciel. Pour cela, revenons au diagramme de cas d'utilisation de la figure 6.16. Deux cas 
n'ont pas ete traites : « Verifier niveau cuve pour remplissage » et « Archiver les trans- 
actions ». Le premier cas n'est pas etudie dans cet ouvrage car il ne presente pas un grand 
interet. L'archivage des transactions est plus interessant. 
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Le diagramme de la figure 6.35 montre comment, en fin de journee, les transactions du jour 
sont archivees. Pour realiser cette fonction, nous ajoutons une nouvelle classe, Gestionnaire- 
DesArchivages. Une seule instance de cette classe est necessaire pour faire fonctionner 
l'archivage. L'objet correspondant est actif une fois par jour (a minuit). II demande l'archi- 
vage des transactions du jour ; apres quoi l'instance de la classe TransactionsDuJour est 
detruite pour etre recreee aussitot (et initialiser ainsi une nouvelle journee de transactions). 



Figure 6.35 

Diagramme qui 
illustre comment le 
gestionnaire des 
archivages realise 
la sauvegarde 
quotidienne des 
transactions. 



sd Archiver les transactions 



7 



: TransactionsDuJour 



: GestionnaireDesArchivages 



loop 



II est minuit a Thorloge 



: TransactionsDuJour 



systeme 



MODELE DES ETATS DE ['APPLICATION 



L' etude de Fapplication a conduit a l'ajout de classes supplementaires. II faut a present 
reperer parmi ces classes celles qui engendrent des instances ayant des etats complexes, et 
pour chacune d'elles, suivre la demarche suivante : 

• identifier des classes de Fapplication avec des etats complexes ; 

• trouver les evenements ; 

• construire les diagrammes d'etats ; 

• verifier la coherence avec les autres modeles. 

Cette etude, bien qu'indispensable, n'a pas ete reproduite ici car elle n'est pas d'un grand 
interet pedagogique. 

Ajout des operations 



La phase d'analyse de notre logiciel est a present presque achevee. II reste a ajouter des 
operations aux classes. Les operations peuvent etre deduites des cas d'utilisation et 
des scenarios. 

Considerons a nouveau le diagramme de la figure 6.31 (ou le test sur le nombre de pistolets 
decroches a ete omis). Reecrivons les messages destines aux objets en respectant la syntaxe 
des messages utilises dans les diagrammes de sequence (voir chapitre 3). 
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Figure 6.36 

Les messages 
destines aux objets 
mis a la norme 
des diagrammes 
de sequence. 



sd ArniementPompe (incut client : Client, inout pompiste : Pompiste, inout session : SessionDePriseDeCarbutant, 
inout pompe : DispositifDePompage) 



pompc : DispositifDePompage 



session : SessionDePriseDeCarburant 



client : Client 



pompiste : Pompiste 



niveau SufiisantPourArmement 



niveauSuftisantPouiArmement : vrai 
> 



RAZ eompteur volume 



2 - 



armement : vrai 
» 



et montant + prix du litre | 



annementPompe 



Affiche confirmation armement 
3> 



Chaque message destine a un objet devient une operation pour la classe correspondante. La 
classe Cuve par exemple contient a present Foperation niveauSuffisantPourArmement() : 
booleen comme le montre la figure 6.37. 



Figure 6.37 

Ajout d'une operation 
a la classe Cuve. 



Cuve 



niveau : entter 



niveauSuffisantPourArmementO : booleen 



Proceder ainsi systematiquement pour tous les diagrammes d'interaction produits permet 
d'ajouter des operations aux classes. La figure 6.38 montre des classes qui concernent la 
prise de carburant auxquelles ont ete ajoutees des operations. 
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Figure 6.38 

Quelques classes 
du domaine avec 
leurs operations. 



SessionDePriseDeCarburant 



demandeArmementPompe : booleen 
decrochagePistolet( numeroPompe : entier, typeCarburant : TypeCarburant ) 
raccrochagePistolet 

appuiGachette 
relachementGachette 



Gachette 



appuyee : booleen 



appuyer 
relacher 



PriseDeCarburant 



quantiteCarburant : reel 



getQuantiteCarburant : reel 



DispositifDePompage 



arme : booleen 
actif : booleen 



armement : booleen 
armer : booleen 

desarmer : booleen 
activer : booleen 

desactiver : booleen 



Phase de conception 

La phase d'analyse est a present terminee. L'etude a permis de preciser l'etendue des besoins 
auquel doit repondre le logiciel de gestion d'une station-service, mais aussi a specifier et a 
comprendre ce qu'il doit faire. Dans la phase suivante, la conception, il s'agit de decider 
comment realiser ce logiciel. Cette phase passe par de nombreuses etapes ou UML n'est pas 
utile (le choix des ressources necessaires pour executer le logiciel par exemple). Dans la suite 
de ce chapitre, nous nous interessons aux seules etapes ou UML est utile. 



Conception du systeme 



1. Decomposez le systeme en sous-systemes. 

2. Reperez les objets qui s'executent concurremment. 



1. Isoler la couche metier pour prevoir la reutilisabilite des classes du domaine . Un 

decoupage possible en sous-systemes est presente a la figure 6.39. II y a quatre couches : 

• Tout en haut, la couche de presentation contient l'interface homme machine du pom- 
piste. 

• Les classes controleurs {SessionDePriseDeCarburant, SessionDePaiement et Gestionnaire- 
DesArchivages) constituent la couche applicative. 
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• La logique metier est composee des classes du domaine (representees ici par les paque- 
tages qui les contiennent). 

• La gestion des peripheriques (capteurs de niveau des cuves, gestion des pompes et du 
terminal de paiement) est incluse dans la couche de services. 

A noter la relation de dependance qui existe entre la couche applicative et la couche de ser- 
vices : elle indique que l'archivage dans la base de donnees (non representee) est directe- 
ment gere par le gestionnaire de la persistance (GestionnairePersistan.ee) sans passer par la 
couche metier. 



Figure 6.39 

Architecture du 
logiciel de gestion 
de la station-service. 




« layer » 
Logique applicative 

+SessionDePriseDeCarburant 

+SessionDePaiement 
+ GestionnaireDesArchivages 




« layer » 
Logique metier 




I s 



« layer » 
Services 



+PiloteGestionCuve 
+Pompe 
+PiloteGestionPaiement 
+GestionPersistance 



Le systeme a done ete decoupe en couches horizontales. L' application, essentiellement con- 
tenue dans la couche applicative, permet, grace aux classes controleurs, de realiser les cas 
d' utilisation. Sans ses classes controleurs, couche applicative et couche metier seraient 
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melangees a tel point que la reutilisabilite des classes de la couche metier serait compromise. 
La separation entre logique applicative et logique metier permettra a une autre application 
de reutiliser les classes du domaine. 

Augmenter la reutilisabilite par partie du logiciel. Le decoupage en couches precedent a 
permis d'isoler la partie metier (les classes du domaine) afin de ne pas Fencombrer avec les 
details de l'application. Une autre partition du logiciel est possible par fonctionnalites. 
D'ailleurs, bien souvent, ces deux types de decoupage sont realises simultanement. 

Une partition fonctionnelle a deja ete realisee quand nous avons separe les classes du 
domaine en deux paquetages (figure 6.11). II est possible d'isoler les paquetages en les pla- 
cant dans un classeur structure (voir Fannexe B). La figure 6.40 presente un classeur struc- 
ture qui contient le paquetage ServiceCarburant. 



Figure 6.40 

Structure interne 
du classeur structure 
PriseCarburant. 



PriseCarburant 








ServiceCarburant 















Le classeur PriseCarburant interagit avec son environnement via des ports (figure 6.41). 
Certains recoivent Fetat des capteurs pistolet et gachette, d'autres servent d'interface avec le 
pompiste ou avec le moteur de la pompe, d'autres encore servent a recuperer la quantite 
d'essence pompee. 

InterfacePompiste 

Ports du classeur 

PriseCarburant. W 



Entree etat 
capteur pistolet 



InterfacePistolet 



InterfaceGachette 



a 



a 



Entree etat 
capteur 
gachette 



PriseCarburant 



Sortie 
commandes 
pompe 



< 



Sortie quantite essence pompee 



InterfaceDebitmetre 
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Ces interfaces ont ete elaborees a partir des classes contenues dans le paquetage du classeur 
structure. Par exemple, la classe SessionDePriseDeCarburant contient une operation desti- 
nee au pompiste, deux operations qui servent d'interface avec le pistolet, et deux operations 
qui sont reliees a la gachette. 



Figure 6.42 

Separation 
des operations 
de la classe 
SessionDePriseDe 
Carburant pour 
preparer les 
interfaces. 



SessionDePriseDeCarburant 



demandeArmementPompe : booleen 
decrochagePistolet( numeroPompe : entier, typeCarburant : TypeCarburant ) 
raccrochagePistolet 

appuiGachette 
relachementGachette 



~y operation invoquee par le pompiste 
1- operations liees au pistolet 
operations liees a la gachette 



On retrouve ces trois ensembles d'operations dans les trois interfaces : InterfacePompiste, 
InterfacePistolet et InterfaceGdchette (figure 6.43). Ainsi, une seule classe interne a un clas- 
seur structure peut etre accessible via plusieurs interfaces. 



Figure 6.43 

Interface qui indique 
si le pistolet est 
range. 



« interface » 
InterfacePistolet 



decrochagePistolet( numeroPompe : entier, typeCarburant : TypeCarburant ) 
raccrochagePistolet 



« interface » 
InterfaceGachette 



appuiGachette 
relachementGachette 



« interface » 
InterfaceDebitmetre 



getQuantitePompee : reel 



« interface » 
InterfacePompiste 



demandeArmementPompe() : booleen 

gefNumeroPompe() : entier 
getTypeCarburantQ : TypeCarburant 
priseCarburantTerminee 



La figure 6.44 montre comment le classeur structure PriseCarburant interagit avec son envi- 
ronnement quand un client appuie sur une gachette. Cette information est transmise au 
composant CapteurGdchette, puis circule via l'interface InterfaceGdchette jusqu'au classeur 
structure PriseCarburant. Ce classeur est alors considere comme une boite noire (le compo- 
sant CapteurGdchette n'a pas acces a sa structure interne). II adopte un certain comporte- 
ment qui engendre eventuellement une commande sur son port de sortie. Cette commande 
est repercutee jusqu'au moteur de la pompe en passant par le composant Pompe qui imple- 
mente l'interface InterfacePompe (figure 6.45). 
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Figure 6.44 

Cheminement d'une 
information depuis 
I'appui sur une 
gachette jusqu'd 
la commande du 
moteur de la pompe. 




5 



InterfaceCapteurGachette 



J — - : CapteurGachette 



I 



« unite centrale » 
Systeme infonnatique de la station 
service 



: Pompe 



Entree etat 
capteur 
gachette 



PriseCarburant 



Sortie 
commande s 
pompe 



InterfacePompe 



InlerraceGficluuic 



Figure 6.45 

Vue detaillee de 
I'interface qui 
contrdle le moteur 
de la pompe. 



« interface » 
InterfacePompe 



armer : booleen 
desarmer : booleen 

activer : booleen 
desactiver : booleen 



Le classeur PriseCarburant doit parfaitement s'inserer dans l'application. Pour le verifier, les 
scenarios issus de l'analyse de l'application peuvent etre repris arm de montrer comment le 
classeur interagit avec son environnement. 

Utiliser un classeur structure muni de ports permet d'isoler la structure interne du classeur 
de son environnement. Le but etant de pouvoir facilement reutiliser ce classeur dans un 
environnement qui se conforme aux interactions imposees par ses ports. Le decoupage 
opere avec le classeur PriseCarburant pourrait etre reproduit pour la gestion des transac- 
tions. Le systeme informatique de la station-service ainsi decoupe gagne en modularite. 
Chaque sous-systeme, qui est isole dans un classeur structure, peut etre facilement extrait 
du contexte de l'application courante et utilise dans une autre application. 
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Figure 6.46 

Classeur structure 
dont le comportement 
est decrit par une 
interaction. 



PriseCarburant 




ServiceCarburant 



2. Le modele des etats d'un systeme est generalement utilise pour reperer les objets qui 
s'executent en parallele : deux objets s'executent potentiellement en parallele s'ils peu- 
vent recevoir des evenements en meme temps sans interagir. Si les evenements ne sont 
pas synchronises, ces objets ne peuvent pas etre traites dans le meme thread de controle. 

Dans notre cas, les evenements qui concernent la prise de carburant par un client ainsi 
que le paiement sont sequentiels. En revanche, chaque client doit avoir sa propre session 
de prise de carburant et de paiement. Les instances des classes SessionDePriseDeCarburant 
et SessionDePaiement s'executent toutes en parallele sans interagir, sauf au moment 
de l'archivage des transactions. L'archivage est sous le controle d'un objet du type 
GestionnaireDesArchivages (figure 6.35). Que se passe-t-il alors si un client paye apres 
s'etre servi de l'essence a minuit, au moment ou l'archivage se declenche ? L'archivage 
utilise une instance des TransactionsDuJour (figure 6.35) et cette meme instance peut etre 
utilisee concurremment par une session de paiement pour y ajouter la transaction d'un 
client (figure 6.34). Le diagramme de la figure 6.47 utilise l'operateur d'interaction par 
pour montrer que le gestionnaire des archivages et la session client peuvent acceder 
concurremment a l'instance de TransactionsDuJour (le deuxieme operande est extrait de 
l'interaction de la figure 6.34, ou seul le message « Ajouter la transaction client » est pris 
en consideration). Pour que la session de paiement ne vienne pas perturber l'archivage, 
cette fonction est realisee dans une section critique grace a l'operateur d'interaction 
ritical (voir chapitre 3). 
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Figure 6.47 

Concurrence d'acces 
sur ^instance des 
transactions du jour. 



sd archiver les transactions + se servir 



: Trans actionsDu Jour 



: GestionnaireDesArchivages 



: SessionDePaiement 



par consider] archiver, il est minuit a Thorloge systeme, ajouter la transaction client }^ } 



critical 



archiver 



II est minuit i 



: Tran sac tionsDu Jour 



l'horloge systeme 



critical 



I 



Ajouter la transaction client 



Conception des classes 

LUi!2lL£l Les diagrammes d'activite sont utiles a toutes les etapes du developpement d'un systeme. 

En phase de conception, ils permettent de decrire le fonctionnement interne des methodes 
des classes afin de preciser les algorithmes utilises. 

Considerons le diagramme de sequence suivant extrait du scenario de paiement par carte 
bancaire au moment ou le pompiste valide la transaction du client. Celle-ci est alors ajou- 
tee a l'ensemble des transactions du jour (instance de la classe TransactionsDuJour) . 

Decrivez a Faide d'un diagramme d'activite comment la transaction du client est ajoutee a 
l'ensemble des transactions du jour. 
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Figure 6.48 

Diagramme de 
sequence pour 
I'archivage 
de transactions. 





Indications : on suppose que les transactions du jour sont structurees en tableau, et que les 
transactions y sont triees par ordre croissant de leur montant en euros. 



Solution 



Diagramme de 
sequence pour 
I'archivage de 
transactions. 



tl : TransactionClient 


t2 : TransactionClient 


1 0 euros 


12,3 euros 



tn : TransactionClient 



47 euros 



L'algorithme utilise pour ajouter une nouvelle transaction consiste a parcourir le tableau a 
la recherche de 1'emplacement ou ajouter la transaction, puis a faire de la place pour la 
nouvelle transaction en decalant les transactions existantes. 

L'algorithme propose correspond a un tri par insertion, dont une modelisation est proposee 
a la question 3 de l'exercice 3 du chapitre 5. La seule contrainte imposee par l'activite tri 
insertion est que le type contenu dans le tableau passe en argument realise l'interface Com- 
parable. II suffit done d'ecrire un comparateur entre deux transactions qui corresponde a 
Fordre propose: tl < t2 equivalent a tl. montant < t2.montant. Cela peut s'implementer 
directement comme un operateur en C++, ou comme une methode en Java. 
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Annexe A 

Comparatif des outils 
de modelisation 



Introduction 

Pour se servir efficacement d'UML, il faut utiliser un outil adapte a vos besoins. L'abon- 
dance de l'offre en la matiere rend son choix tres difficile. L'objectif de cette annexe est d'en 
presenter brievement quelques-uns afin de permettre le choix rapide et efficace de l'outil le 
mieux adapte. Un accent sera mis sur le cout des licences. Nous preciserons, en particulier, 
si les outils disposent d'une licence dite academique, permettant aux professionnels debu- 
tants, aux etudiants et aux formateurs d'illustrer l'interet d'UML, sans devoir, dans un 
premier temps, investir dans une licence onereuse. 

Pour un simple editeur de diagramme UML, adapte aux phases d'analyse et de conception, 
Foffre est large, et le choix de l'outil importe finalement peu, pourvu que son ergonomie 
soit raisonnable (placement des objets et des arcs, navigation entre les diagrammes...). 
On pourra alors regarder du cote de l'open-source ou les plugins ou petits outils UML 
abondent (BoUML, ArgoUML, TopCased. . .), ou utiliser une version « modeler » d'un 
outil professionnel. 

Un des interet de la modelisation qui accompagne le developpement informatique est, d'un 
cote, la production de code et, de l'autre, la generation de modeles a partir du code. 

De ce fait, il est important que votre outil propose des fonctions de retro-ingenierie (extrac- 
tion de modele depuis le code) et reciproquement de generation de code depuis le modele 
(en general surtout les diagrammes de classe, parfois aussi machines a etat). L'ideal dans 
les phases de conception detaillee et d'implementation est que l'outil s'integre dans votre 
environnement de developpement de code (IDE) pour permettre de garder une bonne syn- 
chronisation entre le code et les modeles. II faut egalement exiger de l'outil qu'il soit capable 
de generer un document lisible et imprimable, contenant les differents diagrammes qui 
composent un modele. 

La majorite des outils sont disponibles en version devaluation limitee dans la duree, done 
n'hesitez pas a en telecharger deux ou trois avant de fixer votre choix ; l'echange de modeles 
entre outils est quasiment impossible. 

La liste ci-apres est triee par nom d'editeur. 
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Compagnie : vendeur de l'outil 
Produit : nom du produit decrit 

Licence academique : existe-t-il une licence gratuite pour les enseignements ? 

Licence commerciale : prix de la licence commerciale, varie beaucoup selon le nombre de 

postes, d'utilisateurs. . . 

IDE : l'outil s'integre-t-il dans un environnement de developpement integre ? 
Langages : pour quels langages les traductions code <-> UML sont-elles possibles ? 
Description : une breve description de l'outil. 

+ Points forts de l'outil 

- Points faibles 

Compagnie : Borland 

Produit : Together 

Licence academique : essai 15 jours 

Licence commerciale : prix disponible en contactant leur service commercial (!) 
IDE : Eclipse 

Langages : Java, BPMN (Business Process Modeling Notation) 

Description : d'une ergonomie sans faille, robuste et rapide, cet outil offre de nombreux 
services support (verification de contraintes OCL, audit de projet, extraction de dia- 
grammes de sequence depuis le code, transformation de modeles). Outil reellement 
de qualite industrielle, qui accompagne le developpement de l'analyse des besoins au 
developpement du code. 

+ Ergonomie, prise en main. 
+ Synchronisation code Java. 

- Difficulte d'obtention de licence. 

Compagnie : Gentleware 
Produit : Poseidon 

Licence academique : Community Edition, severement bridee 
Licence commerciale : Professional Edition, 700 a 1 200 € 

IDE : Professional Edition integree dans Eclipse, Community Edition outil java standalone 
Langages : Java 

Description : base sur l'outil open-source gratuit ArgoUML, l'ergonomie de Poseidon 
reste a revoir. II est parfois choisi cependant pour sa facilite de deploiement (32 Mo, tele- 
chargement sans questions). La politique commerciale de Gentleware a voulu pousser, 
depuis 2005, sa communaute d'utilisateurs gratuits a passer a la version payante, avec 
pour resultat un outil CE aux fonctions appauvries (pas d'extraction de modele), ce qui 
est un peu dommage. 

+ Editeur graphique UML entree de gamme. 

- Ergonomie et fonctionnalites limitees. 



Compagnie : IBM/Rational 
Produit : Rational Rose Enterprise 

Licence academique : complete sous programme « IBM Academic Initiative » negociable 

par les enseignants. 

Licence commerciale : 5 000 alO 000 € 

IDE : Standalone, integration partielle dans Visual Studio 2005 
Langages : Visual C ++, Visual Basic 6, Ansi C ++, SQL, Java (1.4) 

Description : Rose a ete le premier outil de modelisation UML, au debut des annees 2000. 
II n'a pas ete mis a jour pour supporter UML 2, il reste cependant un outil tres agreable a 
manipuler, et il supporte bien Finteraction avec les technologies Microsoft, ainsi qu'avec 
les bases de donnees. A noter qu'il existe egalement un produit IBM offrant du support 
pour C#, mais qui n'est pas inclus dans Rose. 

+ Ergonomie bien travaillee. 
+ Importation de projets Visual. 

- Ne supporte pas UML 2. 

Compagnie : IBM/Rational 

Produit : Rational Software Architect 

Licence academique : complete sous programme « IBM Academic Initiative » negociable 

par les enseignants. 

Licence commerciale : 4 000 a 12 000 € 

IDE : base sur Eclipse 

Langages : Java, C ++, Corba 

Description : un outil enorme, par sa taille (6 Go disque, 1 Go RAM), mais aussi par ses 
capacites plus avancees que la concurrence. Construit sur Eclipse, supporte bien tout 
UML 2. Notons que l'offre de IBM/Rational se decline en plusieurs variantes, ce produit 
constitue leur haut de gamme. 

+ Modelisation tres avancee, bon support des diagrammes de sequence, machines a etat. 
+ Services de generation de code/extraction de modele. 

- Lourdeur de l'outil, necessite une grosse configuration pour tourner correctement. 

Compagnie : Microsoft 
Produit : Visio 

Licence academique : inclus dans le lot Microsoft MSDN Academic Alliance 
Licence commerciale : 360 a 780 € 
IDE : Visual Studio (menu Visio) 
Langages : (partiel) C#, VB. Net 

Description : Visio est d'abord un outil de dessin puissant, permettant de produire assez 
facilement des diagrammes techniques de bonne qualite graphique. Une palette conte- 
nant les elements des diagrammes UML est incluse avec l'outil. Visual Studio offre egale- 
ment une option permettant de produire des diagrammes de classe sous Visio a partir 
d'un projet, mais cela reste relativement limite. Certaines des illustrations de ce livre sont 
realisees a l'aide de Visio. 

+ Logiciel de dessin au rendu graphique agreable. 

- Pas reellement un outil UML. 
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Compagnie : No magic 
Produit : MagicDraw UML 

Licence academique : version bridee a l'edition de diagrammes disponible par negociation 
des enseignants 

Licence commerciale : 400 a 2 150 € 
IDE : Eclipse, NetBeans, JBuilder 
Langages : Java, C ++, C# (partiel) 

Description : un outil assez plaisant visuellement, et d'une ergonomie globalement bonne. 
MagicDraw offre un certain nombre de services de transformation de modeles et de defini- 
tion de profils. L'interaction avec le Java est assez bonne (creation de diagrammes de 
sequence depuis le code), les fonctionnalites pour le C ++ et C# sont beaucoup plus limitees. 

+ Un outil honnete, au rendu graphique et a l'ergonomie au dessus de la moyenne. 

- La version offerte aux enseignants ne permet que le dessin. 

Compagnie : Omondo 
Produit : EclipseUML 

Licence academique : version « Free edition », quelques fonctionnalites bridees 
Licence commerciale : version Studio 2 500 a 7 100 € 
IDE : Integration Eclipse 
Langages : Java, J2EE 

Description : un des premiers plugins UML pour Eclipse, base sur les standards open-source. 
Specialement dedie au Java, offre une bonne synchronisation code/diagrammes de classe. 
Les autres diagrammes sont cependant dans l'ensemble plutot delaisses, meme si un editeur 
graphique sommaire est fourni pour chaque type de diagramme. Permet d'avoir une visua- 
lisation UML du code du projet dans les phases de conception detaillee et d'implementation. 

+ Synchronisation avec le code Java (jdk < = 1.6), integration dans Eclipse. 
+ Facile a telecharger et installer. 

- Supporte surtout les diagrammes de classe. 

Compagnie : Visual-Paradigm 
Produit : Visual-Paradigm for UML 

Licence academique : Programme Academic Partners, version standard gratuite negociable 

par les enseignants 

Licence commerciale : 400 a 1 200 € 

IDE : integration dans la majorite des IDE, effort particulier pour Eclipse 
Langages : Java, C ++, PHP, SQL-JDBC, Ada, Python. . . Support partiel d'autres langages 
Description : un outil assez agreable visuellement et ergonomique pour l'edition de dia- 
grammes. La version standard offerte aux enseignants inclut suffisamment de fonction- 
nalites pour etre vraiment utilisable, une version « logiciel de dessin UML » gratuite est 
disponible. Les differents diagrammes sont faciles a construire. Beaucoup de fonctionna- 
lites sont proposees pour interagir avec les bases de donnees. 

+ Interface ergonomique. 

+ Bon support pour une large palette de langages. 

- Documentation proche de la publicite, difficile parfois de trouver Finformation 
pertinente. 
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Annexe B 

Classeurs structures 



Les classes decouvertes au moment de l'analyse (celles qui figurent dans le diagramme de 
classes) ne sont pas assez detaillees pour pouvoir etre implementees par des developpeurs. 
L'analyse montre ce que doit faire un systeme mais pas comment il doit etre realise. C'est le 
role des concepteurs de faire des choix de realisation. Une technique de conception consiste 
a decomposer un systeme jusqu'a ce qu'apparaissent des niveaux de details suffisamment 
fins pour permettre l'implementation. UML propose de partir des classeurs decouverts au 
moment de l'analyse tels que les classes, les sous-systemes, les cas d'utilisation, et de 
les decomposer. Les classeurs ainsi decomposes s'appellent des classeurs structures. lis se 
presentent comme des classes qui montrent leurs structures internes. Un classeur structure 
est constitue de plusieurs parties reliees par des connecteurs. La figure B. 1 illustre une com- 
mande de billets de spectacle par un client via un classeur structure. 



Figure B.l 

Une classe structuree. 



role 



type 



commandeBillet 



client : Personne 



1..* 



billetCommande : Billet 



partie connecteur multiplicite 

Chaque classeur est constitue de parties specifiques : une partie ne peut pas figurer dans 
deux classeurs. Cette condition permet de decomposer un classeur sur plusieurs niveaux. 



Definition 




Une partie est un fragment d'un classeur structure 



Notation 

Comme un classeur, une partie est representee par un rectangle contenant une etiquette 
dont la syntaxe est : 

<nomDuR61e> [ ' : ' <nomDuType> multiplicite ] 

Tandis que les parties d'un classeur structure representent une structure de donnees, les 
roles correspondent a ses differents comportements et permettent de definir le contexte 
dans lequel il est utilise. 
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Un classeur interagit avec son environnement via des ports (voir chapitre 2) par ou passent 
des messages. La figure B.2 illustre l'utilisation des ports dans une classe structuree. 



Figure B.2 

Une classe structuree 
avec des ports. 
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Annexe C 

Composants 

Un composant est une unite autonome au sein d'un systeme ou sous-systeme. C'est un 
classeur structure particulier, muni d'une ou plusieurs interfaces requises ou offertes, pos- 
siblement a travers des ports explicitement represented. Son comportement interne est 
totalement masque de l'exterieur, seule ses interfaces emergent du composant. Le modele 
de composants favorise la reutilisation en fournissant un grain plus grassier que celui des 
classes, qui permet d' avoir des entites reellement autonomes. 

Le programmation par composants constitue une evolution technologiques en matiere 
de programmation, soutenue par de nombreuses plateformes (composants EJB, CORBA, 
COM+ ou .Net, WSDL . . . ) . L' accent est sur la reutilisation du composant, et son evolution 
de facon independante des applications qui Futilisent. Un composant peut etre deploye 
dans diverses configurations, selon ses connexions avec les autres elements du systeme. Au 
contraire, une classe est liee de facon figee au systeme dont elle fait partie, les associations 
avec les autres classes representant des liens structurels. En ce sens, sans perdre la generalite 
d'un classeur, un composant est plus proche d'une instance de classe que d'une classe, et 
les diagrammes de composants s'apparentent plus a des diagrammes des objets qua des 
diagrammes de classe. 

Un composant est represents a l'aide d'un rectangle comme un classeur ordinaire, muni du 
mot-cle « component », et optionnellement d'un graphisme particulier (figure C.l) place 
dans un angle. 
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Figure C.l 

Un composant 
avec une interface 
requise et une 
interface offerte. 



Persistance 





£1 


«component» 




Persistance 





-c 



BaseDeDonnees 



« L.U I IIJJ U lie 1 1 1» 


_C — 1 




«provided interface* 




Persistance 




creer 




stacker 




charger 




«required inteface» 




BasesDeDonnees 




JDBC 





Les composants sont realises par des ensembles de classeurs, qui implementent le comporte- 
ment declare par les interfaces du composant. Un composant peut etre realise de differentes 
manieres, sans affecter ses interfaces. La seule contrainte pour pouvoir substituer un com- 
posant a un autre est de preserver les interfaces requises et offertes. La facon dont un 
composant est realise peut etre definie a plusieurs niveau de detail. 

Un composant peut etre vu comme une boite noire. On ne fait alors emerger que ses interfa- 
ces et Ton utilise une des presentations de la figure C.l. 

On peut egalement decrire la structure interne du composant en boite blanche. On expose 
ainsi la facon dont le composant est realise, avec une representation proche de celle d'un 
claseur structure. On connecte alors les ports externes du composant aux ports des classeurs 
constituant ses parties, par un arc qui represente une relation de delegation (figure C.2) : les 
messages qui arrivent sur ce port sont directement transmis au composant interne. Cette 
vision hierarchique permet de decomposer un systeme en sous systemes relativement inde- 
pendants, et done plus reutilisables. Les interfaces requises et offertes sont connectees entre 
elles pour exprimer l'assemblage des parties realisant le composant. 



Figure C.2 

La realisation d'un 
composant exposee 
en boite blanche. 
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Annexe E> 

Diagramme 
de deploiement 

UML n'est pas limite a la production de modeles utiles aux phases d' analyse et de conception. 
Le deploiement qui precede la mise en production constitue une etape importante du deve- 
loppement d'un systeme. Au final, ce dernier va s'executer sur des ressources materielles 
(processeurs, memoire, etc.) dans un environnement particulier. UML permet de represen- 
ter un environnement d'execution ainsi que des ressources physiques (avec les parties du 
systeme qui s'y executent) grace aux diagrammes de deploiement. L'environnement d'exe- 
cution ou les ressources materielles sont appeles « noeuds ». Les parties d'un systeme qui 
s'executent sur un noeud sont appelees « artefacts ». Un artefact peut prendre la forme 
d'un fichier binaire executable, d'un fichier source, d'une table d'une base de donnees, d'un 
document, d'un courrier electronique, etc. 

La figure D. 1 represente le deploiement d'un serveur Web avec lequel une machine cliente, 
dotee d'un navigateur Web, communique. Le serveur, qui est connecte a une base de donnees 
installee sur une machine tierce, execute Fartefact site WEB. 

Figure D.l 

Diagramme de 
deploiement pour 
un serveur Web 
qui presente des 
instances de nceuds 
et une instance 
d'artefact deployee. 



« artefact » 
siteWEB 



Le diagramme de la figure D.l contient des instances de noeuds. A un niveau d'abstraction 
plus eleve (au niveau des noeuds), ce diagramme peut se representer de la facon suivante. 

Figure D.2 

Diagramme de 
deploiement pour 
un serveur Web 
qui presente des 
nceuds. 



client : PC 



serveurWEB : Serveur 



serveurBaseDeDonnees : ServeurSGBD 



fl 



"5 

I 

I « deploye » 
I 

J 




240 UML 2 



Les associations entre les noeuds sont des chemins de communication tels que des cables 
reseaux, des bus, etc., qui peuvent porter une multiplicity : la figure D2 presente plusieurs 
PC qui sont connectes au site Web du serveur. 



Definition 

Un nceud est une ressource sur laquelle des artefacts peuvent etre deployes pour etre exe- 
cutes. Un artefact est la specification d'une entite physique du monde reel. 

Notation 

Un nceud se represente par un cube dont le nom respecte la syntaxe des noms de classes (voir 
chapitre 2). Le nom d'un nceud instancie doit etre souligne (figure D.l ). 

Un artefact se represente comme une classe par un rectangle contenant le mot-cle artefact 
suivi du nom de I'artefact. Celui-ci est souligne quand il s'agit d'une instance. Un artefact 
deploye sur un nceud est symbolise par une fleche en trait pointille qui porte le stereotype 
deploye et qui pointe vers le nceud (figure D. 1 ). L'artefact peut aussi etre inclus directement 
dans le cube representant le nceud. 

Plusieurs stereotypes standard existent pour les artefacts : document, executable, fichier, 
librairie, source. 

Annexe E 

Implementation cTun 
modele objet en Java 

Dans le cycle de developpement d'un systeme, l'implementation correspond a la phase 
de realisation. Quand il s'agit d'un logiciel, cela consiste a traduire les modeles d'analyse et de 
conception dans un langage de programmation. Cette phase peut etre automatisee en partie 
avec des outils informatiques de modelisation. Ces outils sont nombreux (GDPro, Object- 
Team, Objecteering, OpenTool, Rhapsody, STP, Visio, Visual Modeler, WithClass, ...). 
Certains supportent UML depuis ses debuts (Rose de Rational Software), d'autres viennent 
du monde du logiciel libre (ArgoUML). Nombreux sont les outils qui permettent la gene- 
ration automatique de code a partir d'un diagramme de classes vers des langages de pro- 
grammation varies (Java, C++, C#, etc.). Dans la suite de ce paragraphe, nous montrons 
comment implementer les elements essentiels d'un diagramme de classes, et comment tra- 
duire les messages des diagrammes d'interaction (de sequence ou de communication) en Java. 
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Notation 



Les implementations vers differents langages sont assez proches les unes des autres. A partir 

d'une implementation en Java, il est done facile de passer d d'autres langages. 

Une implementation dans un langage donne peut etre realisee de differentes manieres. 



Implementation de l'heritage 



Figure E. 
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Implementation d'un heritage 

public class Voiture{ 

public void seDeplacer( ) { 



// 



} 



} 



public class VoitureAEssence extends Voiture{ 
} 



Figure E.2 
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Implementation d'une interface 

public interface Vehicule{ 
public void seDeplacer( ) ; 

} 



public class Voiture implements Vehicule{ 
public void seDeplacer( ) { 



// 



} 
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Implementation des relations entre classes 



Les langages de programmation comme Java n'offrent pas de technique particuliere pour 
implementer des associations, des agregations ou des compositions. Ce type de relation 
s'implemente en ajoutant des attributs dans des classes. 



Figure E.3 
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Association unidirectionnelle de 1 vers 1 



public class Emplacement 
} 



public class Exemplaire{ 
private Emplacement rangee; 

public void setEmplacement ( Emplacement emplacement ){ 
this. rangee = emplacement; 

} 

public Emplacement getEmplacement ( ) { 
return rangee; 

} 

public static void main( String [] args ){ 
Emplacement emplacement = new Emplacement () ; 
Exemplaire exemplaire = new Exemplaire( ) ; 
exemplaire . setEmplacement ( emplacement ); 
Emplacement place = exemplaire . getEmplacement () ; 

} 

} 



Remarque 

Pour acceder a I'association plus facilement (sans passer par les methodes setEmplacement 
et getEmplacement), il est possible de supprimer le mot-cle private (ce n'est possible que si 
les classes font partie d'un meme paquetage). 



Figure E.4 
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Association bidirectionnelle de 1 vers 1 



package bagnole; 
public class Conducteur{ 
Voiture voiture; 

public void setVoiture( Voiture voiture ){ 
if( voiture != null ){ 
this. voiture = voiture; 
voiture. conducteur = this; 

} 

} 

public static void main( String [] argv ){ 
Voiture voiture = new Voiture(); 
Conducteur conducteur = new Conducteur( ) ; 
conducteur. addVoiture ( voiture ); 

} 

} 

package bagnole; 
public class Voiture{ 
Conducteur conducteur; 

public void setConducteur( Conducteur conducteur ){ 
this . conducteur = conducteur; 
conducteur. voiture = this; 

} 

} 



Figure E.5 
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Association unidirectionnelle de 1 vers plusieurs 

public class Client{ 
} 

import java.util. Vector; 
public class Entreprise{ 

private Vector clients = new Vector(); 

public void addClient( Client client ){ 
clients . addElement ( client ); 

} 

public void removeClient ( Client client ){ 
clients . removeElement ( client ); 

} 

public static void main( String [] argv ){ 
Entreprise monEntreprise = new Entreprise( ) ; 
Client client = new Client(); 
monEntreprise . addClient ( client ); 
monEntreprise . removeClient ( client ); 

} 
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Figure E.6 
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Association bidirecrionnelle de 1 vers plusieurs 

import java.util. Vector; 
class Oeuvre{ 

Vector exemplaires = new Vector(); 

public void addExemplaire ( Exemplaire exemplaire ){ 
if( exemplaires . contains ( exemplaire ) == false ){ 
exemplaires . addElement ( exemplaire ); 

} 

} 

public void removeExemplaire( Exemplaire exemplaire ){ 
if( exemplaires . removeElement ( exemplaire ) == true ) 
exemplaire . oeuvre = null; 



} 



){ 



public static void main( String [] argv 
Oeuvre donGiovani = new Oeuvre(); 
Exemplaire exemplaire = new Exemplaire( 1 
donGiovani. addExemplaire ( exemplaire ); 

} 



); 



} 



class Exemplaire{ 
int numero; 
Oeuvre ceuvre; 

public Exemplaire ( int numero ){ 
this. numero = numero; 

} 

public void setOeuvre( Oeuvre oeuvre ){ 
if( oeuvre != null ){ 

oeuvre . exemplaires . addElement ( this ); 
this. oeuvre = oeuvre; 

} 

} 

public void removeOeuvre( Oeuvre oeuvre ){ 

if( oeuvre . exemplaires . removeElement ( this ) == 
this. oeuvre = null ; 

} 

public boolean equals( Object obj ){ 

if( (obj!=null) && (obj instanceof Exemplaire; 

return numero == ( (Exemplaire)obj ) .numero; 
else return false; 

} 

} 



true ) 



Figure E.7 
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Composition 

public class Voiture{ 
private class Moteur{ 

} 

private Moteur moteur; 

} 

Agregation : une agregation s'implemente comme une association 



Implementation de l'envoi de messages 



Figure E.8 
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Implementer les messages des diagrammes de communication 

public class Conducteur{ 
private Voiture voiture; 
public void setVoiture( Voiture voiture ){ 
if( voiture != null ){ 
this. voiture = voiture; 

} 

} 

public void conduire(){ 
voiture . demarrer ( ) ; 
} 

public static void main( String [] argv ){ 
Voiture voiture = new Voiture(); 
Conducteur conducteur = new Conducteur( ) ; 
conducteur . setVoiture ( voiture ); 
conducteur. conduire( ) ; 

} 

} 

public class Voiture{ 

public void demarrer(){ 
// ... 

} 

} 

Implementer les messages des diagrammes de sequence 

Ce diagramme est equivalent au precedent au niveau interpretation et donne done lieu au 
meme code (voir figure E.9). 
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Figure E.9 
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Annexe F 

Organisation d'UML 2 



Differences vues d'UML 2 



Le langage UML s'integre dans toutes les phases du cycle de vie du developpement, allant de 
la collecte des besoins au deploiement. UML ne definit pas de processus de developpement. 
II est utilisable avec la plupart des processus existants. UML donne la possibilite d'utiliser 
les memes concepts et notations, sans necessiter de conversion, dans les differentes phases 
de developpement. II est, de ce fait, bien adapte au cycle de developpement iteratif et 
incremental. 

Organisation en paquetages 



Un paquetage definit des regroupements qui repondent aux contraintes applicatives et aux 
besoins du developpement. Dans la version 2 d'UML, un modele est defini par un paquetage 
qui comprend une description complete d'un systeme a partir d'un point de vue specifique. 
Le metamodele UML, qui est aussi compose d'un ensemble de modeles, est modelise par 
des paquetages. Les principales caracteristiques des normes OMG sont regroupees dans le 
paquetage dit Core. UML, CWM, MOF, les profils et les autres metamodeles utilisent les 
standards specifies dans le modele Core, comme le montre la figure F.I. 
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Figure F. 1 




Chaque modele (paquetage) est, a son tour, compose de plusieurs sous-paquetages, ce qui 
confere a UML une organisation arborescente. Plus on remonte vers la racine, plus on s'eleve 
dans le niveau d'abstraction. Par exemple, le modele Core contient les sous-paquetages 
PrimitivesTypes, Abstractions, Basic et Profils, comme le montre la figure F.2. 



Figure F.2 
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Selon le meme principe, chaque paquetage est, lui-meme, compose de plusieurs sous- 
modeles. Par exemple, le modele de la superstructure d'UML 2, qui permet de specifier la 
syntaxe des modeles utilisateurs, est compose, entre autres, d'un modele de classes, d'un 
modele d'interactions, d'un modele de profils et d'un modele de cas d' utilisation, comme le 
montre la figure E3. 
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Figure F.3 
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composant la 
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langage UML 2. 
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Couches du metamodele 



Les paquetages definissent la hierarchie d'abstraction entre les differents modeles, mais ne 
mettent pas en evidence les differentes couches de modelisation, en particulier les differen- 
ces entre les metamodeles et le modele de donnees. L'OMG propose une organisation en 
couches de ses langages parmi lesquels figure UML 2. Les caracteristiques qu'ils partagent 
sont regroupees dans le metamodele MOF. Linstanciation de ce metamodele donne nais- 
sance a des langages comme UML et CWM. Lutilisateur d'UML definit des classeurs (clas- 
ses, associations...) decrivant son application en respectant les specifications du 
metamodele UML. Un modele utilisateur bien employe garantit un modele d'objets physi- 
ques actifs, avec des proprietes bien definies. 

Une architecture de modelisation se compose de quatre couches : les couches MO, Ml, M2 
definissent respectivement les instances actives du modele utilisateur, le modele de donnees 
utilisateur, et le metamodele UML, la facon dont est construit ce dernier etant specifiee par 
la couche M3. Lexemple presente a la figure F.4, extrait de la specification de la superstruc- 
ture du langage UML, illustre les quatre couches. 

La video (aVideo) qui est en train d'etre visionnee est une instance active : elle se situe au 
niveau MO. Cette video est une instance de la classe Video (diagramme de classes), en 
Foccurrence l'instance « 2001 : A spaceOdyssey » (diagramme d'objets). Les diagrammes de 
classes et d'objets correspondent au modele utilisateur: ils sont done au niveau Ml. La 
classe Video et les attributs quelle contient sont modelises dans le respect du metamodele 
UML, qui specifie comment definir une classe et un attribut : ils font done partie de la cou- 
che M2. Un attribut, une classe et une instance respectent les specifications MOF. Au niveau 
de la couche MOF, ils sont specifies par une classe (cela correspond a la couche M3). 
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Les paquetages et les couches donnent une organisation architecturale du langage UML. Un 
utilisateur n'a pas besoin de connaitre cette organisation pour bien utiliser ce langage. II doit 
se contenter de respecter la syntaxe et la semantique d'UML. II doit egalement connaitre les 
differents diagrammes mettant en valeur tantot des aspects statiques, tantot des aspects 
comportementaux du systeme. Une organisation conceptuelle des differents diagrammes 
UML permet d'avoir une vision plus claire des vues offertes par ce langage. Les trois auteurs 
a Forigine d'UML proposent un decoupage conceptuel en quatre domaines : structured 
dynamique, physique et gestion de modeles. Chaque domaine est compose de plusieurs 
vues et chaque vue est realisee par un ensemble de diagrammes UML. 

Domaine structurel 

Le domaine structurel est compose des trois vues suivantes : 

• La vue fonctionnelle. Elle conceptualise et structure les besoins de l'utilisateur (dia- 
gramme de cas d'utilisation). Elle definit le contour du systeme a modeliser en definis- 
sant les fonctionnalites principales sans pour autant chercher l'exhaustivite. Elle sert 
d'interface entre les differents intervenants dans le projet. 

• La vue statique. Elle definit les principaux classeurs de Fapplication. Elle est modelisee 
par un ensemble de classes dotees d'attributs et d'operations. Celles-ci sont organisees 
via des relations de composition, de generalisation, etc. Des objets en execution peuvent 
etre modelises pour illustrer leur comportement et leurs relations. La vue statique se pre- 
sente essentiellement sous forme de diagrammes de classes et d'objets. 

• La vue conceptuelle. Elle met en evidence les collaborations entre classeurs et decrit 
Farchitecture physique du systeme. Elle est realisee par le diagramme de collaborations et 
le diagramme de composants. 
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Domaine dynamique 

Le domaine dynamique regroupe l'ensemble des vues montrant le comportement du sys- 
teme a P execution : la vue des interactions (diagramme d'activites), des machines a etats 
(diagramme d'etats-transitions), des interactions (diagramme de sequences et diagramme 
de communication) 

Domaine physique 

Le domaine physique est compose de la seule vue de deploiement. Elle decrit l'emplacement 
physique du materiel utilise et la repartition des composants sur ce materiel. Ces ressources 
sont modelisees par des nceuds interconnectes. Cette vue est particulierement importante 
dans le cas de la modelisation des environnements distribues oil une place importante est 
donnee a Fexpression des exigences en termes de performances. 

Domaine gestion de modeles 

Le domaine gestion de modeles montre une organisation en paquetages du modele lui- 
meme. II est realise via le diagramme de paquetages et est compose de deux vues : 

• La vue des profils. Les profils permettent d'apporter des changements restreints aux 
modeles UML pour les adapter a des outils ou plates-formes tout en conservant l'intero- 
perabilite. Ces changements sont assures par des mecanismes d'extension du langage. Les 
deux principaux elements d'extension en UML sont les contraintes et les stereotypes. On 
appelle « profil » un ensemble coherent de stereotypes avec les contraintes associees. 

• La vue de gestion de modeles. Elle modelise l'organisation du modele par un ensemble 
de paquetages et leurs relations. Un modele est defini par un point de vue et un niveau de 
precision. Le choix de la granularite des paquetages et de la maniere de les organiser defi- 
nissent la vue de gestion du modele. 
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